[petsc-dev] plans for PETSc release
jed at jedbrown.org
Sun Apr 24 12:38:16 CDT 2016
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
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
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
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
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
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
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
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 818 bytes
Desc: not available
More information about the petsc-dev