Re: [rdf4j-dev] Release planning

[Peter Ansell <ansell.peter@xxxxxxxxx>]

~8 weeks between minor versions sounds good to me. Previously we had
about 4-6 weeks between patch versions which worked fairly well, but
extending that to a regular 8 week period should also work. Whether it
is 7 or 9 is neither here nor there really in the greater scheme, as
long as the dates are available in advance.

If reviews for new versions/dependencies are already included in the
feature-cutoff period then that is great, but otherwise could you also
get some guidance from legal about the expected timeframes for
reviewing new dependencies and new dependency versions to add to the
basic timelines.

Are we strictly following SemVer in terms of the major/minor/patch
version naming and public API compatibility together with that
timeline? And if so, it would be great to clarify the public API
extent. Ie, foo-api modules are obvious additions to the public API,
but how far do we go into internal classes before they are classed as
internal and able to be deprecated/migrated during the minor
versioning cycle.

Cheers,

Peter

On 2 September 2016 at 14:17, Jeen Broekstra <jeen.broekstra@xxxxxxxxx> wrote:
> 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.
>
> The simplest way I can think of is that we go for a fixed-length (say 8
> week) release cycle. That gives us a framework where we can say "2.1.0 will
> happen in 8 weeks from now, 2.2.0 8 weeks after that", etc.
>
> 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).
>
> Let me know what you think of this approach.
>
> 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.
>
> _______________________________________________
> rdf4j-dev mailing list
> rdf4j-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from
> this list, visit
> https://dev.eclipse.org/mailman/listinfo/rdf4j-dev
>