search

atoum / atoum.github.io

Atoum website
http://atoum.github.io
2 stars 8 forks source link

Release policy #16

Closed jubianchi closed 6 years ago

jubianchi commented 8 years ago

As said during the Forum PHP 2015, we should give our users a clear view of how/when we release atoum.

Here are some notes I have on this:

@atoum/rms feel free to comment on this, suggest new entry or fix some of them. Once we are OK with those rules, I'll write a blog post.

Grummfy commented 8 years ago

:+1: But for extension we need to do it only for official, I think. Le 13 janv. 2016 9:03 PM, "Julien BIANCHI" notifications@github.com a écrit :

As said during the Forum PHP 2015, we should give our users a clear view of how/when we release atoum.

Here are some notes I have on this:

  • strictly stick to semver (x++ if BC breaks, y++ for any new feature, z++ for any bug-fix)
  • 1 release every 6 weeks (minor)
  • release ASAP for any bug (patch)
  • every major is supported for 1 year after the last minor/patch release
  • after 1 year, we may break BC if required (and start a new major) wether the last major reached EOL or not
  • next major may start before the previous one reaches EOL
  • next minor/patch release source code lives on the master branch

If 2 major releases are living side-by-side

  • the oldest will have its own branch and the newest will live on the master branch
  • bug-fixes will be backported
  • features will be backported if possible

Extensions/Stubs

  • will be released in-sync with atoum to conform to breaking changes (new atoum major release)
  • may be released at the same time (minor)
  • released ASAP for any bug-fix

@atoum/rms https://github.com/orgs/atoum/teams/rms feel free to comment on this, suggest new entry or fix some of them. Once we are OK with those rules, I'll write a blog post.

— Reply to this email directly or view it on GitHub https://github.com/atoum/atoum.github.io/issues/16.

mikaelrandy commented 8 years ago

Seems good to me, but i need explanations on this point :

  • after 1 year, we may break BC if required (and start a new major) wether the last major reached EOL or not

What is the point ?

jubianchi commented 8 years ago

@Grummfy sute this only applies to official extensions (I.E those under the atoum org) ;)

@mikaelrandy Given the rules I wrote, a release EOL date is determined by the last minor/patch release of it. But if at some point (after one year of the major life) we identify that breaking BC somewhere allows us to add new cool features (in atoum itself or through extensions) we start a new major.

Starting a new major will for sure have a side-effect: efforts will be more important on the last major than on the previous so it's worth warning users that after one year of life we may start a new major and ship less new things on the previous one.

jubianchi commented 8 years ago

I'm wondering if we should add a rule saying that we limit living major versions to a maximum of 2. Once we have to start a third one, the oldest will die.

Hywan commented 8 years ago

@jubianchi We can add such a rule yes. It might not happen but who knows :-). I would not say anything about extensions however. We can't make such hard assumption on the whole atoum's ecosystem. This is hard to maintain and keep.

mikaelrandy commented 8 years ago

@jubianchi +1 on the rule about limiting numbers of living major version

jubianchi commented 8 years ago

We should add a note on deprecations:

mikaelrandy commented 8 years ago

:+1:

Grummfy commented 7 years ago

I have started to work on this #68