[pgrouting-dev] pgRouting Release Process Checklist

Daniel Kastl daniel at georepublic.de
Thu May 30 17:38:24 PDT 2013


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-Checklist<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
Web: http://georepublic.de
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/pgrouting-dev/attachments/20130531/1aa9da14/attachment.html>


More information about the pgrouting-dev mailing list