[Neos] [Team] Neos 1.2 / Flow 2.3 Feature Freeze

[Robert Lemke]

Hi Aske,

thanks for the elaborate reply.

> On 11 Aug 2014, at 20:03, Aske Ertmann <aske at moc.net> wrote:
> 
> The reason for bringing this up is due to the health of the release. We are currently in a situation where the master branch contains at least one broken feature and a somewhat unstable/unfinished implementations of constraints and content dimension. This means that releasing a beta doesn’t make much sense and is a waste of end users time. I don’t think it makes sense to not finish (meaning disabling or reverting) these features and do a release without them since we’re very close, so we need some time to finish those before releasing a beta.
> 
> An additional argument is that we currently have quite some reviews in our queue that has haven’t been tackled, meaning features have been merge ready for quite some time but are lacking reviews. Skipping these features is a bad signal to send to the community.

To me it's important that we don't fix / announce release dates, but we do announce feature freeze dates (to developers). This is a big difference. You may or may not tag a first beta on the day of feature freeze, so if you don't feel comfortable releasing the beta 1 then really, feel free to schedule it so that everything is good enough for a beta.

My point is that we must, at some point, stop producing new features for a specific release. Considering your email, I propose that you, as the release manager, create a list of features which have not been merged yet and must go into 1.2. Based on that list let's have a quick vote here to see if the team generally agrees. And then we must not add more features.

> - Move the feature freeze date to august 29th

I really suggest to not move the feature freeze date, but rather create the list mentioned above. You can decide on a per-case basis if an additional feature is necessary to complete the major features we created, but let's not open completely new cans at this stage.

> - Focus on releasing long overdue patch releases for 1.1 and 1.0

That's another topic - we really should have a fixed schedule for these and put that on auto-pilot. There's hardly any work involved with releasing a patch level version (and if so, let's fix that).

> - Branch out for 1.2 as soon as it makes sense, not necessarily a feature freeze (allows for merging Flow 2.4 features e.g.)

we should branch out when we release beta 1 - that doesn't need to happen at the same time with a feature freeze.

> - Switch focus on finishing existing features and getting into release mode

+1

> - There will very likely be a lack of resources of finalizing the release, like there was with the previous release
> - We will have to spent time implementing feature switches for or reverting unfinished features
> - It won’t include some of the features that are just lacking review
> - We probably won’t be able to focus on getting patch releases out any time soon
> - Still time for finalizing the release on the upcoming code sprint in august
> - Have a rushed release IMO
> - Probably won’t be ready for beta before a week or two anyway, meaning shorter stabilising period

please allow me to be picky on this list. Having a feature freeze now does not exclude any of the points above. We can take all time we need to produce a stable release, a feature freeze does not imply a rushed beta phase or stable release.

> I think this is a realistic plan that will ensure that the release will be done properly, after all we have quite limited resources. Let’s avoid repeating the last release process just because of a tentative date we agreed upon.

The date was not really important to me, neither is sticking to principles. What I would like to achieve is that we are getting used to merging features or parts of features which are so stable that we could potentially release at any given time. And that needs practice. IMO, creating feature switches should be part of our development routine for bigger new features. It takes so much pressure out of the whole release cycle.

Cheers,
Robert