[cdt-dev] CDT Release plan proposal for the upcoming year

[Marc Khouzam <marc.khouzam@xxxxxxxxxxxx>]

Hello,

we had a detailed discussion at the CDT summit about our upcoming release strategy.  Here is the proposal we came up with.  Please review and voice your concerns if any.

Summary
=======
The Neon simultaneous release will have 3 update release instead of the traditional 2.  CDT would follow the simultaneous release as follows:

- June 2016 - Neon - CDT 9.0
- September 2016 - Neon.1 - CDT 9.1* (from the master branch)
- December 2016 - Neon.2 - CDT 9.2* (from the master branch which then becomes open for Oxygen development)
- March 2017 - Neon.3 - CDT 9.2.1** (from the cdt_9_2 maintenance branch)
- June 2017 - Oxygen - CDT 9.3 (from the master branch)

1- We propose to add an automatic and continuous maintenance release whenever a fix is available on the maintenance branch.
2- We propose having an update site with a generic name like "maintenance" which will provide all the above builds in sequence.
3- We also propose an official "nightly builds" update site which will provide users with our nightly builds, if they so choose.  This p2 entry will be present but disabled by default in users' installations but can be turned on if they are interested.

* If such minor releases don't have any new features or new APIs, they can be converted to maintenance releases
** We recommend a maintenance release for Neon.3 so as to open up master to use Oxygen's new APIs.  Doing a minor release in March would require it to work with Neon, which prevents from using Oxygen APIs.  We felt that opening up master in December was a good enough window to work with Oxygen APIs.

Details
=====
We discussed the conflicting goals of getting new features to our users quickly, versus providing a lot of stability in our releases.  It was brought up that some software packages provide multiple "channels" for their releases, as to address such conflicting goals.

Based on this idea we propose (as summarized above) that CDT automatically provides two update sites:
1- "official release" - All manual releases + automatic *maintenance* releases
2- "nightly build" - Automatic nightly builds off master

The two update sites would be part of CDT's p2.inf file, to make them automatically visible in users' list of update sites.  The "official release" one will be enabled by default, while the "nightly build" one will be disabled by default.

Automatic and continuous maintenance releases should be done nightly if there is a change (as our build job does now).  No version change will be done, we'll rely on the qualifier changing.  Our Hudson build would copy the build to the update site location automatically, maybe only if the tests pass.  This should require no manual effort.

The nightly build update site will have dependencies on projects that don't have a matching release.  To make this work, CDT will need to provide a release including all the necessary dependencies.  This type of update site should be mirrored.  We would try to keep up to 7 of such builds and provide them in a composite update site.  This will allow user to revert if a particular build causes problems.