RFC: Timeline

[bajtos]

I am proposing to set an aggressive timeline for the next version and remove any features that are not done on time. Preliminary proposal:

1. 2016-03-31: Any feature that's not mostly complete is removed from this release. (The definition of mostly is intentionally left vague.)
2. 2016-04-30: Feature freeze. Any feature/change not finished by this time is removed from the release.
3. Next 3-6 months: stabilize the code, integrate with APIC and to other tasks required for a new release.

This is based on my experience with managing 3.0 release - even though we drastically reduced the scope of the release in May 2016 (using the rule described in my step 1 above) , the first release candidate was not released until October 2016 and the GA was announced in December. I.e. it took us more than 6 months to finish a release. Projecting this experience to loopback-next and my proposed dates, loopback-next will be released in 2017Q4.

@ritch @raymondfeng @superkhau

[superkhau]

I agree, we need to be quite aggressive with timelines in the beginning to even have a chance at Q4 this year. 👍

[ritch]

I think endless convorsations with tons of text is a keystone habit that we need to avoid in order to get something out by summer. Code > Convo.

[ritch]

Our timeline goal is 6/1/2017 to release loopback@4.0.0.

[crandmck]

Our timeline goal is 6/1/2017 to release loopback@4.0.0.

Do you mean for GA, or RC? I assume you mean GA.

At risk of stating the obvious, the "timeline" needs to be more than just one date. At a minimum, we need to work backward from GA date and specify dates for RC(s), feature freeze, and "spec freeze" (high-level features decided). This will determine exactly what we believe we can realistically deliver by that date.

[bajtos]

At risk of stating the obvious, the "timeline" needs to be more than just one date. At a minimum, we need to work backward from GA date and specify dates for RC(s), feature freeze, and "spec freeze" (high-level features decided). This will determine exactly what we believe we can realistically deliver by that date.

+1 ✖️ 💯

Do you mean for GA, or RC? I assume you mean GA.

FWIW, loopback@3.0.0 was the first release candidate version. I think this approach worked out reasonably well and is worth repeating.

Having said that, the question whether 2016-06-01 is the deadline for RC or GA remains unanswered.

[ritch]

GA

[superkhau]

Closing in favour of https://github.com/strongloop/loopback-next/wiki/Upcoming-Releases. Changes should be announced there.