[pgrouting-dev] pgRouting Release Process Checklist

[Stephen Woodbridge]

On 5/30/2013 9:10 PM, Daniel Kastl wrote:
>
>
>
> On Fri, May 31, 2013 at 9:51 AM, Worth Lutz <wal3 at mindspring.com
> <mailto:wal3 at mindspring.com>> wrote:
>
>     __ __ __ __
>
>     I think that you all have seen this but here is the description of
>     the way I’m trying to use git.____
>
>     __ __
>
>     http://nvie.com/posts/a-successful-git-branching-model/
>
>
>
> Yes, this is a popular way and we have added a few notes to the Wiki:
> https://github.com/pgRouting/pgrouting/wiki/2.0-Development-Guidelines-and-Standards#git-branching-model
>
> I think once everything is sorted and cleaned up we will follow this
> from version 2.0
> Right now we only do it partially.

Yes, I really like this model and keep a copy here on my desktop. I have 
been using it for big changes. For little stuff, I just work in the 
develop branch, but the problem is that things that start out small 
often turn into larger projects.

I also need a better way from the command line to know what branch I'm 
in because a few times I have been in the wrong branch and made changes 
which is just as big a problem as forgetting to make a branch.

But, yes really good stuff, and incorporated in our developer guide.

Thanks for the suggestion,
   -Steve

> Daniel
>
>
>     ____
>
>     __ __
>
>     __ __
>
>     Worth____
>
>     ------------------------------------------------------------------------
>
>     *From:*pgrouting-dev-bounces at lists.osgeo.org
>     <mailto:pgrouting-dev-bounces at lists.osgeo.org>
>     [mailto:pgrouting-dev-bounces at lists.osgeo.org
>     <mailto:pgrouting-dev-bounces at lists.osgeo.org>] *On Behalf Of
>     *Daniel Kastl
>     *Sent:* Thursday, May 30, 2013 8:38 PM
>     *To:* __pgRouting developers mailing list__
>     *Subject:* Re: [pgrouting-dev] pgRouting Release Process Checklist____
>
>     __ __
>
>     __ __
>
>     __ __
>
>     On Fri, May 31, 2013 at 5:23 AM, Stephen Woodbridge
>     <woodbri at swoodbridge.com <mailto:woodbri at swoodbridge.com>> wrote:____
>
>     Daniel, et al,
>
>     I have taken a first pass at defining a pgRouting Release Process
>     Checklist in the Wiki:
>
>     https://github.com/pgRouting/pgrouting/wiki/pgRouting-Release-Process-Checklist
>
>     We need to review and expand on this list and I would like to see
>     each step documented in enough detail that someone not familiar with
>     the process could follow the check list and cut a release of a new
>     version.____
>
>     __ __
>
>     Thanks, Steve!____
>
>     I have added a few points and made a few modifications.____
>
>     Github actually already provides source tarballs if there is a
>     release tag.____
>
>     I also think that a stable release will go to master branch, right?____
>
>     ____
>
>
>         For example I do not know who (email addresses) needs to be
>         notified?____
>
>     __ __
>
>     I think we should see that everyone, who wants to be notified is
>     subscribed to the right channels.____
>
>     ____
>
>         ____
>
>         We need to had what is our version/tag naming conventions?____
>
>     __ __
>
>     I think this became a common schema and I would like to use it:
>     http://semver.org/____
>
>     "Wrong" version names like "1.05" make
>     packaging unnecessarily complicated (lessons learned from Ubuntu
>     packages ;-) ____
>
>     __ __
>
>     ____
>
>         How do we know when it is appropriate to make a tag or a
>         release?____
>
>     __ __
>
>     I would say we make a tag when we make a release.____
>
>     So the question is when we make a release:____
>
>     For "alpha", "beta" and "rc" it should be OK if the source is at
>     least passing the tests.____
>
>     For a stable release I would say, when there are no more tickets for
>     that milestone in the issue tracker and so complaints about the last
>     RC.____
>
>     __ __
>
>     ____
>
>
>         We have put a lot of work into making our project consistent
>         internally, and I want to make sure that we have repeatable
>         processes so we are consistent externally as we make releases.____
>
>     __ __
>
>     The day before I tried to switch branch names by making a "develop"
>     branch from master and merging "sew-devel-2_0".____
>
>     There was no problem, so I think I will do this change when
>     ____Boston____ is sleeping.____
>
>     ____
>
>     Daniel____
>
>     __ __
>
>     __ __
>
>     ____
>
>
>
>     ____
>
>     __ __
>
>     --
>     Georepublic UG & Georepublic ____Japan____
>     eMail: daniel.kastl at georepublic.de <mailto:daniel.kastl at georepublic.de>
>     Web: http://georepublic.de <http://georepublic.de/> ____
>
>     ------------------------------------------------------------------------
>
>     No virus found in this message.
>     Checked by AVG - www.avg.com <http://www.avg.com>
>     Version: 2013.0.3343 / Virus Database: 3184/6369 - Release Date:
>     05/30/13____
>
>
>     _______________________________________________
>     pgrouting-dev mailing list
>     pgrouting-dev at lists.osgeo.org <mailto:pgrouting-dev at lists.osgeo.org>
>     http://lists.osgeo.org/mailman/listinfo/pgrouting-dev
>
>
>
>
> --
> Georepublic UG & Georepublic Japan
> eMail: daniel.kastl at georepublic.de <mailto:daniel.kastl at georepublic.de>
> Web: http://georepublic.de <http://georepublic.de/>
>
>
> _______________________________________________
> pgrouting-dev mailing list
> pgrouting-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/pgrouting-dev
>