| [rdf4j-dev] Release planning |
|
Hi devs, I want to propose that we start using a regular 8-week release cycle for RDF4J (for new minor/major releases, not for patch versions). The reason I want this is that minor/major releases require an
official Eclipse release
review - including legal rubberstamping of the code and
dependencies and a full release plan, description of new features
etc to be approved by the PMC. Such a review typically needs one
or two weeks to be finalized, which means that I need to have the
details of the release fairly fixed well in advance. Moreover,
these reviews are in fixed cycles, concluding on every first and
third Wednesday of the month. In other words: we need to plan our
releases to coincide with this review cycle. Everybody who has a new feature can work on it at her/his own
tempo. However, about 3 weeks before the end of each release cycle
I will need a definite yay or nay from you: will your feature be
done in time for the next release? If yes, great, it goes into the
release and I can include it in our planning for the review. If
not (or unsure), no worries, it just can't go in this release, and
you will have to wait another 8 weeks before we do a release with
your feature. Given that we can't release until Eclipse review is complete, and
this happens on either the first or third Wednesday of the month,
I'd schedule our actual release date on the first or third
Thursday (I realize this means that every so often we will have a
release cycle that is either 7 or 9 weeks long, but we can live
with that I'm sure). Does everybody agree with this as a good principle to work on? Anything unclear?
If we go with this, then (taking 2.0 release as the starting
point), the release date for RDF4J 2.1.0 is Thursday, October
20 The feature cutoff date is Thursday, September 29.
Just to be clear: the feature cutoff date does not mean you have
to stop working - it's just the date at which I need your definite
commitment that the feature will be done in time. Throughout the
review phase we're free to continue fixing bugs and tweak minor
things. Finally, patch releases are not part of this cycle; they are done as soon as one or more fixes are complete for it and I (or another dev) feel it is a good time to do a release. There's no official review necessary so we can do this quickly, when we feel like it. I will communicate my intent to release a new patch version a few days in advance so that others who have a last-minute fix can raise their hand and contribute. If you miss the cutoff: no biggy, there'll be another release soon enough. However, from now on we do need to be strict about what goes into
a patch release. Bug fixes only. No exceptions (and yes, I have
been quite guilty myself of trying to sneak minor improvements
in). Jeen PS those of you who are not full committer cannot assign your GitHub issue to a release milestone yourself. I will try to do this for you, but please keep an eye on it, and don't hesitate to post a comment to ask me to schedule it for a (different) release. PPS it is my intent to stop doing parallel Java 7 releases for the next minor release. So there will be no RDF4J 1.1 parallel to 2.1. If you dislike this, please step up and volunteer to help maintain the branch. |