I have not seen any actual enforcement of the m4 rule in past simrel. Largely, that's because it doesn't make much sense for projects that release more frequently than once a year. Say the project has a release 5.2 scheduled to wrap up during m4 time frame. The next release is of unknown length at that time (depends on actual community participation). The project can then either (a) contribute 5.2 to Mars or (b) gamble that by the time Mars GA rolls around, they will be on some version like 5.4 even if there is not even a branch or a plan for that release yet. If the project opts for option (a), we can very well end up in a situation that what ships with the shiny new Mars release is two to three releases out of date. If the project opts for option (b) they may end up in a situation where they have to issue filler releases just to catch up with the declaration or miss the declaration and contribute an earlier version.
Simrel process should not require projects to declare a particular release version. Rather, the process should focus on the type of changes being contributed at a particular date. For instance, "you cannot contribute breaking changes after mX" is better than "you cannot switch contribution version after mX". - Konstantin From: [email protected] [mailto:[email protected]] On Behalf Of Wayne Beaton Sent: Wednesday, July 30, 2014 12:14 PM To: [email protected] Subject: Re: [cross-project-issues-dev] Wish to contribute SWTBot to Luna aggregator, and to PDE EPP package The primary intent behind a plan is to give potential contributors some sense of how they can contribute. I have no trouble putting you down for 2.2.1 for now with an expectation that--should you receive contributions that warrant the creation of a new release--you'll create a new release record (say 2.3.0) at a later date. The actual name of your release and whether or not you create a new release record is not nearly as important as making sure that you get proper practice participating in the release and that your bits don't break the aggregation. So declaring a new release before M4 isn't as important to me as making sure that you know what bits you'll actually be contributing early enough in the cycle to do adequate testing. I hope that this makes sense. Wayne On 07/30/2014 01:04 PM, Mickael Istria wrote: On 07/30/2014 06:47 PM, Wayne Beaton wrote: Can I assume that you mean Mars? ;-) Sure, you can assume that ;) I've started assembling the list of projects/releases that will join Mars [0]. I'll put you down for 2.2.1 for now Thanks. if you do decide to include a different release with Mars, then let us know on this list (before the M4 deadline) and I'll update the record. More generally... participating projects should create a record (if one does not already exist) for the release that they intend to contribute in the PMI and then inform the community via this list. Remember that project plans need to be specified by M4. A minimal plan that includes a description [1] of the release and a list of issues [2] (which we can generate automatically) shouldn't be too onerous, I hope. It would be good if you can capture a theme or two for your plan. SWTBot doesn't really have a plan. People come and contribute what they want, and we release when we feel it's worth it. So I'm already thinking about how to hack this contribution process without planning a release. M4 is in December. Between December and June, there can be something like 3 or 4 releases (or 0) that cannot be planned before M4. In the case of SWTBot, we're not much interested about the Simultaneous Release planning, which for a small project such as SWTBot could prevent from frequent releases if necessary. What interest us is more to be included in Mars site and EPP package and making sure we work well with other projects of this same Mars site. Can the Release Train (or in that case the aggregator only) process handle the possibility of an unexpected release after M4 ? -- Mickael Istria Eclipse developer at JBoss, by Red Hat <http://www.jboss.org/tools> My blog <http://mickaelistria.wordpress.com> - My Tweets <http://twitter.com/mickaelistria> _______________________________________________ cross-project-issues-dev mailing list [email protected] To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev -- Wayne Beaton Director of Open Source Projects, The Eclipse Foundation <http://www.eclipse.org> Learn about Eclipse Projects <http://www.eclipse.org/projects> <https://www.eclipsecon.org/europe2014> EclipseCon Europe 2014
_______________________________________________ cross-project-issues-dev mailing list [email protected] To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
