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”.
From: cross-project-issues-dev-bounces@xxxxxxxxxxx [mailto:cross-project-issues-dev-bounces@xxxxxxxxxxx] On Behalf Of Wayne Beaton
Sent: Wednesday, July 30, 2014 12:14 PM
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.
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 . I'll put you down for 2.2.1 for now
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  of the release and a list of issues  (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 ?
cross-project-issues-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit