Re: [m2e-dev] Release Planning

[Hannes Wellmann <wellmann.hannes1@xxxxxxx>]

Thank you Christoph for your proposal.

 

I support it. It makes the release process more transparent and predictable so everybody knows what can be expected.

Knowing the a due-date for submissions longer in advance could also reduce the endgame rush we just experienced.

 

I just have one remark to point 1:

An issue for each action is a bit too fine grain IMHO. For example if I just perform some clean ups or similar a issue just adds more noise and I have think about an description what is obvious from the code.

I suggest to have an issue only for each feature or greater work, especially if it is a longer running work that is relevant for planning. It can then absolutely be possible to have multiple PRs for one issue.

But if I just find small improvements, apply them and create a PR immediately I don't see a benefit from creating an issue. Discussion about the code can be done better in a PR and for release planning this also not relevant.

 

If there is a final agreement about the release process I suggest to document it. Maybe in the CONTRIBUTING.md. next to the version-bump schema or in a dedicated file (the version rules could then go there as well).

 

Gesendet: Dienstag, 08. Februar 2022 um 11:06 Uhr
Von: "Christoph Läubrich" <laeubi@xxxxxxxxxxxxxx>
An: "Maven Integration for Eclipse developers mailing list" <m2e-dev@xxxxxxxxxxx>
Betreff: [m2e-dev] Release Planning

As the recent discussions and rumor I'd like to propose some kind of
'rules' (maybe there are already some and I haven't found them?) to get
this release stuff more smooth in the future (and even faster releases).

1) We should create an issue for every action (excluding documentation
changes) and either:
- assign the current milestone if we plan to work on this in the
current release cycle
- not assign a milestone if we will do it "sometimes"

2) If we ask for a release, also ask for ultimately marking issues to be
included within a given time frame (I would suggest one week and thus
name it "planning week" from now on) and

3) Then we should discuss in this "planning week" on the marked issues
if they go into the release or should be postponed if there any
concerns. If postponed, we should assign the next milestone or remove it
if we do not want to get this in for the next release.

4) After this "planning week" we assign a release date (github allows to
set a due-date on a release) that should be at most two weeks maybe we
choose then to postpone some things because there is no time to actually
develop this feature ...

5) From now on we only add bugs to the current release, if something is
a bug might be discussed on the ticket.

6) All features should be finished one week before the release so we
have a time where we only work on regressions (if any).

That way we always have a clear understanding what is "open" for the
current release and if there is a risk we miss the date due to the
current status of the milestone.

Given that, we should be able to release once a month if desired and I
think that's acceptable as a lower bound.
_______________________________________________
m2e-dev mailing list
m2e-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/m2e-dev