Hi everyone, I hope you've had a good summer so far.
For those of you trying to beat-the-heat, an air-conditioned office and access to the Cross-Project Mailing List might be the answer. There has certainly been some good discussions happening around Eclipse this summer. As promised, I've summarized the most important issues and I even tried to pull out the important questions (although maybe we want to discuss this a bit more before deciding anything). If I missed anything important, please feel free to respond. After tomorrows meeting I can put this on a wiki.
In my opinion, the most important topic (for the PC to consider) is the frequency of our releases. Doug also started a thread about 'Eclipse as an IDE', which may ultimately impact the planning council -- or impact what the simultaneous release produces -- but I think we should let that one brew a little longer.
The frequency of the release cycle was also started by Doug -- the CDT actually wants to produce two 'releases' each year, each with their own maintenance stream. Konstantin proposed the idea of a rolling release train that anybody can contribute too at any time (the train leaves the station each month, although we could adjust that schedule). At that point: the repository, packages, and presumably the download page would be automatically generated based on the 'released' content. If you didn't choose to release that month, your previous contribution would be used. With this model, projects could decide how often they want to release (with the granularity of 1 month).
As was noted in the discussion, this effectively changes the primary purpose of the SimRel from that of being a Synchronized Repository to that of being Aggregated Repository. That is, a whole bunch of 'released stuff' is available, but it might not all work together.
So the first question is: Do we want to change the purpose of the SimRel to be a rolling aggregation?
Assuming NO. If we choose not to do this and keep the current yearly release structure, we should review our current SRs. In particular, some projects view the SRs as additional release opportunities. Should we change the name of the current Service Releases to indicate that they may include new features?
Also, if we choose to not to have a rolling release, can we leverage the existing milestones builds to give projects a chance to release more often?
Assuming YES. Assuming we want to move to a rolling release schedule, there are a number of things we need to consider.
1. Should we have different streams?
2. Do we need to snapshot things from time-to-time? (i.e. declare that on a particular date Luna is shipped)?
3. Is each snapshot somehow versioned?
4. How do milestones work with a rolling release?
Independent of this, we also need to decide if projects must be required to submit a 'stable' URL to the aggregator?
I'm sure there are other options too (such as an aggregated rolling release with a yearly simultaneous component). I just wanted to try to summarize some the questions we had and give us a framework to discuss this at tomorrow's meeting.
Cheers,
Ian
