[pgrouting-dev] pgRouting Release Process Checklist

[Worth Lutz]

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/

 

 

Worth

  _____  

From: 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> 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-Checkl
ist

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:  <mailto:daniel.kastl at georepublic.de> daniel.kastl at georepublic.de
Web:  <http://georepublic.de/> http://georepublic.de 

  _____  

No virus found in this message.
Checked by AVG - www.avg.com
Version: 2013.0.3343 / Virus Database: 3184/6369 - Release Date: 05/30/13

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/pgrouting-dev/attachments/20130530/64ed4e5f/attachment-0001.html>