[pgrouting-dev] pgRouting Release Process Checklist

pgRouting pgrouting-dev
1

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.

For example I do not know who (email addresses) needs to be notified?
We need to had what is our version/tag naming conventions?
How do we know when it is appropriate to make a tag or a release?

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.

Feedback welcome.

Thanks,
   -Steve

2

On Fri, May 31, 2013 at 5:23 AM, Stephen Woodbridge <woodbri@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&gt;

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 :wink:

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@georepublic.de
Web: http://georepublic.de

3

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@lists.osgeo.org
[mailto:pgrouting-dev-bounces@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@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 :wink:

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@georepublic.de> daniel.kastl@georepublic.de
Web: <http://georepublic.de/&gt; 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

4

On Fri, May 31, 2013 at 9:51 AM, Worth Lutz <wal3@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@lists.osgeo.org [mailto:
pgrouting-dev-bounces@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@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 :wink: ****

** **

****

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@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@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/pgrouting-dev

--
Georepublic UG & Georepublic Japan
eMail: daniel.kastl@georepublic.de
Web: http://georepublic.de

5

On 5/30/2013 9:10 PM, Daniel Kastl wrote:

On Fri, May 31, 2013 at 9:51 AM, Worth Lutz <wal3@mindspring.com
<mailto:wal3@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@lists.osgeo.org
    <mailto:pgrouting-dev-bounces@lists.osgeo.org>
    [mailto:pgrouting-dev-bounces@lists.osgeo.org
    <mailto:pgrouting-dev-bounces@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@swoodbridge.com <mailto:woodbri@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 :wink: ____

    __ __

    ____

        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@georepublic.de <mailto:daniel.kastl@georepublic.de>
    Web: http://georepublic.de/&gt; ____

    ------------------------------------------------------------------------

    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@lists.osgeo.org <mailto:pgrouting-dev@lists.osgeo.org>
    http://lists.osgeo.org/mailman/listinfo/pgrouting-dev

--
Georepublic UG & Georepublic Japan
eMail: daniel.kastl@georepublic.de <mailto:daniel.kastl@georepublic.de>
Web: http://georepublic.de/&gt;

_______________________________________________
pgrouting-dev mailing list
pgrouting-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/pgrouting-dev

6

git branch -v

It will show all your branches with the active one marked.

-----Original Message-----
From: pgrouting-dev-bounces@lists.osgeo.org
[mailto:pgrouting-dev-bounces@lists.osgeo.org] On Behalf Of Stephen
Woodbridge
Sent: Thursday, May 30, 2013 9:29 PM
To: pgrouting-dev@lists.osgeo.org
Subject: Re: [pgrouting-dev] pgRouting Release Process Checklist

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

7

Another thing I use a lot: http://blog.kfish.org/2010/04/git-lola.html

Worth

-----Original Message-----
From: pgrouting-dev-bounces@lists.osgeo.org
[mailto:pgrouting-dev-bounces@lists.osgeo.org] On Behalf Of Worth Lutz
Sent: Friday, May 31, 2013 6:32 AM
To: 'pgRouting developers mailing list'
Subject: Re: [pgrouting-dev] pgRouting Release Process Checklist

git branch -v

It will show all your branches with the active one marked.

-----Original Message-----
From: pgrouting-dev-bounces@lists.osgeo.org
[mailto:pgrouting-dev-bounces@lists.osgeo.org] On Behalf Of Stephen
Woodbridge
Sent: Thursday, May 30, 2013 9:29 PM
To: pgrouting-dev@lists.osgeo.org
Subject: Re: [pgrouting-dev] pgRouting Release Process Checklist

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

_______________________________________________
pgrouting-dev mailing list
pgrouting-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/pgrouting-dev
-----
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2013.0.3343 / Virus Database: 3184/6370 - Release Date: 05/30/13

8

On Fri, May 31, 2013 at 7:54 PM, Worth Lutz <wal3@mindspring.com> wrote:

Another thing I use a lot: http://blog.kfish.org/2010/04/git-lola.html

Or you could try this Bash addition described in the end of the blog post:
http://lancespeelmon.wordpress.com/2012/05/10/three-tips-for-creating-the-best-ever-git-command-line/

I didn't know about, but enable coloring in .gitconfig helps, too.

Daniel

--
Georepublic UG & Georepublic Japan
eMail: daniel.kastl@georepublic.de
Web: http://georepublic.de