[petsc-dev] plans for PETSc release

Jed Brown jed at jedbrown.org
Sun Apr 24 08:06:40 CDT 2016

Satish Balay <balay at mcs.anl.gov> writes:

> Master currently doesn't work as you describe. 

Why doesn't it work that way?  That was the philosophy when we adopted
this branching model years ago, it works reliably for many other
projects, and I thought it worked for us when we used it that way.  Did
something change?

> To me - currently we are at RC [yeah - witout a change in
> petscversion.h or a tag] - and RC to RELEASE should be via maint
> workflow - hence this update to maint.

Why should RC to release "be via maint workflow"?

I'd also argue we're clearly not at RC because new features (currently
in 'next') are still being merged.  After changing 'maint', you still
advised Lisandro to merge new features to 'next' so that they could
later graduate for the release.  If any of those changes affect the API,
then people on 'maint' have gotten an API that will never be released.
This breaks our promises with respect to 'maint'.  The whole point of
that branch is to have something stable that users can update

> I didn't intend to be rude to our 'maint' users. Ideally there should
> have been a tracking branch maint-3.6 always - so users who whish to
> time the switch from 3.6 to 3.7 do this on their terms [and not
> implicitly via maint].
> I'll make an annoucement to maint users about switching to maint-3.6
> branch.

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'.

As for pending merges, what is the status of these branches (in 'next',
but not yet in 'master')?


-------------- 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/6755e3f7/attachment.sig>

More information about the petsc-dev mailing list