Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [eclipse.org-planning-council] Simultaneous ReleaseBrainstorming

We already ship quarterly ;-)

I think one major problem is that not all release train projects know that they can ship new features and APIs with an update release. If we change that perception, we can already improve things quite a bit for our users and deliver things faster to them.

I see two main changes when converting the update releases to "normal" releases:
- It would probably allow (API) breakage like we allow with the yearly release. Not sure whether this is really something good for the community. We should identify just one, or maybe two, releases that allow breakage.
- It reduces the workload on the developers, because they don't have to maintain two streams. They can just release from master.

Dani



From:        Mélanie Bats <melanie.bats@xxxxxxx>
To:        eclipse.org-planning-council@xxxxxxxxxxx
Date:        05.10.2017 15:21
Subject:        Re: [eclipse.org-planning-council] Simultaneous Release        Brainstorming
Sent by:        eclipse.org-planning-council-bounces@xxxxxxxxxxx




Hi,

After a first round about reading the document[1], I would like that we
know start by imagining whet will be the future of the SimRel.

During the call yesterday, the planning council seems to agree that an
evolution of the SimRel habits would be useful and that we should give
up the year long ramp up to provide a predictable short release cycle.

Some points have to be discussed then to see how we go further:

* What it would be exactly ? The idea is to provide no more update but a
new release each time with only one stream. In that case code names
seems meaningless.

* How do we release it ? An option would be to keep only one repository
in place and continuously update it which means from the users point of
view new stuff with every release.

* What would be the cadence ? A quarter release (every 12 weeks) looks
feasible as it is more or less corresponding to the actual milestones
cadence. The main change is that those "milestones" are considered as
releasable.

* How do we ensure API stability & compatibility ? When projects can
make API break? How do we organize API freeze ? How do we deal with
bigger features more than a release ?

* How do we organize the verification & tests in order to evolve from a
by hand homologation to a more automatic one ?
If we imagine that the developments could be done organized on the new
release cycle, do the EDP delays, release review and manual IP log would
scale ?

What do you think about how it should be organized?

Please as Wayne said yesterday do not hesitate to be creative and
propose new things that might be different than what we are used to do.

Best regards,

[1]
https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_document_d_1R3RhAKMFbtBrv3KcyLV48mQJRs59GHao7XEbzZM07Jw_edit-3Fusp-3Dsharing&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=1UITCR5rxUZHSFczvfaNFK4ymEbEiccRX7VKchpqz0Y&m=UczPqreWuL0tVW5amsoxLHuOHsAoMWmz9MInnudsjq8&s=Hlb_hYOqq1abrK7BVif43MUJUsOSMSbe_fHRcD3vT2w&e=
--
Mélanie Bats
CTO
+33 7 87 69 42 84
+33 5 34 57 16 29
@melaniebats

*Obeo*
25 Boulevard Victor Hugo - Colomiers - France
https://urldefense.proofpoint.com/v2/url?u=http-3A__www.obeo.fr&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=1UITCR5rxUZHSFczvfaNFK4ymEbEiccRX7VKchpqz0Y&m=UczPqreWuL0tVW5amsoxLHuOHsAoMWmz9MInnudsjq8&s=YcETkqtc8nqsz_beq8Ez2kYaORm_U2hgr_JDoA2b5aw&e=
_______________________________________________
eclipse.org-planning-council mailing list
eclipse.org-planning-council@xxxxxxxxxxx
https://urldefense.proofpoint.com/v2/url?u=https-3A__dev.eclipse.org_mailman_listinfo_eclipse.org-2Dplanning-2Dcouncil&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=1UITCR5rxUZHSFczvfaNFK4ymEbEiccRX7VKchpqz0Y&m=UczPqreWuL0tVW5amsoxLHuOHsAoMWmz9MInnudsjq8&s=K1BUu3tml3jO9aneEWBDP8ZfHHVICA8eJP8954pGy6Y&e=

IMPORTANT: Membership in this list is generated by processes internal to the Eclipse Foundation.  To be permanently removed from this list, you must contact emo@xxxxxxxxxxx to request removal.




Back to the top