[petsc-dev] plans for PETSc release

[Jed Brown]

Lisandro Dalcin <dalcinl at gmail.com> writes:

> On 24 April 2016 at 16:06, Jed Brown <jed at jedbrown.org> wrote:
>> Okay, but I think we should never do a release this way again.  We
>> should finish all merging to 'master', tag the release on 'master', then
>> fast-forward 'maint' and rewind 'next'.
>
> I'm with Jed. IMHO, that's the right workflow to make a new release.

FWIW, here's gitworkflows(7):

   Branch management for a release
       Assuming you are using the merge approach discussed above,
       when you are releasing your project you will need to do
       some additional branch management work.

       A feature release is created from the master branch, since
       master tracks the commits that should go into the next
       feature release.

       The master branch is supposed to be a superset of maint.
       If this condition does not hold, then maint contains some
       commits that are not included on master. The fixes
       represented by those commits will therefore not be
       included in your feature release.

       To verify that master is indeed a superset of maint, use
       git log:

       Example 5. Verify master is a superset of maint

       git log master..maint

       This command should not list any commits. Otherwise, check
       out master and merge maint into it.

       Now you can proceed with the creation of the feature
       release. Apply a tag to the tip of master indicating the
       release version:

       Example 6. Release tagging

       git tag -s -m "Git X.Y.Z" vX.Y.Z master

       You need to push the new tag to a public Git server (see
       "DISTRIBUTED WORKFLOWS" below). This makes the tag
       available to others tracking your project. The push could
       also trigger a post-update hook to perform release-related
       items such as building release tarballs and preformatted
       documentation pages.

       Similarly, for a maintenance release, maint is tracking
       the commits to be released. Therefore, in the steps above
       simply tag and push maint rather than master.

   Maintenance branch management after a feature release
       After a feature release, you need to manage your
       maintenance branches.

       First, if you wish to continue to release maintenance
       fixes for the feature release made before the recent one,
       then you must create another branch to track commits for
       that previous release.

       To do this, the current maintenance branch is copied to
       another branch named with the previous release version
       number (e.g. maint-X.Y.(Z-1) where X.Y.Z is the current
       release).

       Example 7. Copy maint

       git branch maint-X.Y.(Z-1) maint

       The maint branch should now be fast-forwarded to the newly
       released code so that maintenance fixes can be tracked for
       the current release:

       Example 8. Update maint to new release

       ·   git checkout maint

       ·   git merge --ff-only master

       If the merge fails because it is not a fast-forward, then
       it is possible some fixes on maint were missed in the
       feature release. This will not happen if the content of
       the branches was verified as described in the previous
       section.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20160424/42d44d80/attachment.sig>