[pgrouting-dev] pgRouting Release Process Checklist

[Daniel Kastl]

On Fri, May 31, 2013 at 9:51 AM, Worth Lutz <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.

Daniel




> ****
>
> ** **
>
> ** **
>
> 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-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 ****
>   ------------------------------
>
> 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*
> ***
>
> _______________________________________________
> pgrouting-dev mailing list
> pgrouting-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/pgrouting-dev
>
>


-- 
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/32dbaf96/attachment.html>