[pgrouting-dev] Version numbering suggestion
Worth Lutz
wal3 at mindspring.com
Fri Dec 26 05:12:25 PST 2014
Hi All,
I have been struggling on how to setup my own project workflow and this
discussion seems to follow my thinking.
I'm setting up a gitlab server which is a gitHub like wrapper for git
which can be run on your own server for private work.
Here is a link to a blog on the gitlab website discussing many different
ideas on workflow with git. This discussion may help you determine a
simple workflow which fits the needs of pgRouting.
https://about.gitlab.com/2014/09/29/gitlab-flow/
*Worth Lutz*
------------------
On 12/26/2014 01:53 AM, Daniel Kastl wrote:
>
>
> On Fri, Dec 26, 2014 at 3:18 PM, Paragon Corporation <lr at pcorp.us
> <mailto:lr at pcorp.us>> wrote:
>
> Sounds good to me. Only question I have is
> By release -- do you mean like a stable branch (so bug-fixes can
> be committed to it) or that it is the last one you released and no
> further changes can be made to it.
>
>
> I think "tags" are a good way to mark releases, because Github also
> treats tags as releases somehow:
> https://github.com/pgRouting/pgrouting/releases
> (Need to read about this more)
>
> You can always use a tag as a base for a new branch or whatever else.
> You will find the 2.0.0 release tagged as v2.0.0 as well as
> pgrouting-2.0.0, which was a request by the CentOS packager.
> I'm not sure yet, if it helped to solve the packaging issue. For the
> Ubuntu packages I preferred the short version.
>
> I think having a branch of the latest stable is important,
> particularly if someone runs into a bug and doesn't want to go to
> the development branch that may add more functions.
> Aside from that. My main suggestion is the develop version and
> released version should not have the same version number since
> this just causes confusion for people.
>
>
> They should have a different number. I think it was my fault, because
> I created a new clone of the repository and forgot to copy the
> pre-commit hook.
> A remaining issue with this pre-commit hook is, that it only knows the
> previous hash tag, not the one created with the commit. But I don't
> think there is a solution for this.
>
> Daniel
>
> --
> Georepublic UG & Georepublic Japan
> eMail: daniel.kastl at georepublic.de <mailto:daniel.kastl at georepublic.de>
> Web: http://georepublic.info
>
>
>
>
>
> _______________________________________________
> pgrouting-dev mailing list
> pgrouting-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/pgrouting-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/pgrouting-dev/attachments/20141226/4891aa88/attachment.html>
More information about the pgrouting-dev
mailing list