[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