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

[Aske Ertmann]

Hello

Thanks for bringing this up again, I personally tried bringing it up at the last scrum as - well which lacked attendance - and wanted to do it again today/tomorrow.

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.

I originally proposed to set dates for releases to ensure that we release the current state more often, instead of waiting for certain larger features to be finished. This allows for a more agile development process, which is needed due to the unpredictable nature of our development resources. That being said, I don’t think post-poning a few weeks goes against that. It’s more important to be agile and to look realistically at the situation than focus on fixed release/feature freeze dates. After all we don’t have a fixed amount of resources available, and looking at the history of the previous release finding the necessary resources to do the release is very difficult. I don’t see that situation having changed much. Of course changing the dates should be a reasoned decision. Also I think we need to stick to the release date being flexible as the amount of time needed to make the release stable is impossible to estimate, however again we have a guidance of 4 weeks.

So to ask the question, what will be the consequence of moving the (internal and unannounced) feature freeze date three weeks? Will it hurt project planning? If so, I believe we have a problem that cannot be contributed to the release schedule of Neos. Additionally the specific release date is flexible, so there’s never been any guarantee which you could plan on in any case.

I don’t suggest we try to take a bigger bite than we can chew and try to add more big features that will jeopardise the stability, but rather get a good state for a release. So we should still avoid feature creep in the prolonged feature freeze time.

Why do I think postponing will solve things? Because I for one will actually spend a lot of time working on the release over the next months and I hope others will join the effort as well. Let’s not forgot that doing a release requires a serious amount of effort, just ask Christian or me how much time we spent getting 1.1 out.

So here’s what I’d suggest we do:

- Move the feature freeze date to august 29th
- Focus on releasing long overdue patch releases for 1.1 and 1.0
- 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.)
- Switch focus on finishing existing features and getting into release mode
- Coordinate Flow 2.3 and Neos 1.2 releases

Benefits:

- Allow for merging and finalizing existing features in the queue
- Allow for the upcoming code sprint in august to work on the release
- Allow time for getting release related things done (planning release, documentation, communication, branching etc.)
- Releasing of patch releases
- Ensure the release not to be rushed
- Allow the upcoming code sprint in september/october to finalize the release

Consequences of not doing so:

- 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

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.

Additionally I’d like to point out that when suggesting this to other team members, there was a consensus on doing it. But we still haven’t made an official agreement, which I’d like to do here now. If you have any points to add, please do so there’s a solid foundation for making the decision.

Cheers,
Aske

On 11 Aug 2014, at 15:32, Robert Lemke <robert at typo3.org> wrote:

> Hi Neos team,
> 
> as you may know, Aske raised the topic of postponing the feature freeze for Neos 1.2 during a hangout and on IRC (which implies postponing Flow 2.3, too). I think I fully understand the motivation behind this, and personally I'd love to squeeze in a few more features related to content translation. But from a non-personal standpoint I think that postponing the feature freeze is dangerous.
> 
> The reasoning behind our new release cycle was that
> 
> - we need more regular releases so everybody can plan in Neos updates into their project and knows when an already merged feature will be part of a stable release
> - we can't foresee nor want to restrict ourselves in the amount of time we need to stabilize a beta version
> 
> therefore we agree on not fixing a release date but fixing a feature freeze date.
> 
> All features which are merged until that date will be part of the next release. We have some time (agreed roughly on 4 weeks) to stabilize / fix bugs until a stable release.
> Those features which are partly merged and thus not fully functional will be disabled by a feature switch and their full release is postponed to the next version.
> 
> Let's just check what remains as a valid reason for postponing a feature freeze. In my opinion the only valid reason would be that we have absolutely no interesting and already merged feature for that release.
> Can you think of more reasons?
> 
> Let's discuss this here and then find a good consensus.
> 
> Cheers,
> Robert
> 
> -- 
> Robert Lemke
> Lead Developer TYPO3 Neos and TYPO3 Flow
> Co-Founder TYPO3 Association
> 
> Blog: robertlemke.com
> Get involved: typo3.org – flow.typo3.org – neos.typo3.org
> 
> 
> 
> 
> 
> 
> _______________________________________________
> Neos mailing list
> Neos at lists.typo3.org
> http://lists.typo3.org/cgi-bin/mailman/listinfo/neos