http://en.wikipedia.org/wiki/Intel_Tick-Tock
"Tick-Tock" is a model adopted by chip manufacturer Intel Corporation since 2007 to follow every microarchitectural change with shrinking of the process technology. Every "tick" is a shrinking of process technology of the previous microarchitecture and every "tock" is a new microarchitecture.[1] Every year, there is expected to be one tick or tock.[1]
And now, the same thing for Drupal release management.
"Ping" release (so far this was D5, D6, D7, etc):
- no backwards compatibility
- break existing APIs
- big clean-up.
- big rewrite.
- remove old cruft.
- a few new features.
- new hooks / APIs.
"Pong" release (this would be something new):
- backwards compatible.
- plenty of testing for backwards compatibility.
- don't break existing APIs.
- minor cleanup and refactoring
- new features
- usability improvements
- performance improvements
- new hooks and APIs.
minor releases (so far this was 6.1, 6.2, 6.3, etc)
- bug fixes
- critical performance improvements
- any stuff that is really "minor".
For D7, this would have meant:
D7 "Ping": fields in core
D7 "Pong": D7UX
(and other things, obviously)
(EDIT)
A few situations where I would imagine this to be useful.
- Controversial, immature or never-going-to-be-finished new features or usability improvements can be postponed to a mid-step-release.
- Valuable improvements, such as "Secure Password Hashes" can be backported to previous branches and released as mid-step.
- New hooks can be added in mid-step releases, to react to evolving needs in contrib.
- New features can be started in contrib to mature, and added back into core as a mid-step release (if this is ever desirable).
A question is about how we manage this with git:
Does everything need to go into the next "major" release, before it is backported to the "mid-step" one? Or do we not start the "major" one before we release the "mid-step" ? Or do we do this in parallel ? How hard would that be to merge later, now that we are on git?
This could kill the idea..
And, another question, what about version numbers? Would we need a new naming scheme?
Would we have more than one mid-step release, before the next major release?
Comments
Different angle
Different angle based on the D6, D7 and D8 only, and related more to management.
Ping (D7, D8):
- Bright and fascinating engineering initiatives, lack of big picture and of usability vision
- Dramatic finish as new initiatives don't fit each to other (obvious in the absence of big picture)
- Breaking a lot of functionalities due to the above
- Shirty contributing developers come back to D6. D6 shines in its "second life"
- A lot of non-coordinated rewrites
- Finally D7 seems to work in most of use cases
Pong:
- group therapy, never closed (this is dangerous)
- New fascinating engineering visions (D8), etc.
- Some new functionalities, with foggy rationale, implemented in D8 and backported to D7
- ...
How to overcome above weaknesses?
Maybe practical step could be massive analysis of features requests in all the tickets, not only those regarding core.
If I understand correctly, we
If I understand correctly, we do already have these problems with the current release policy.
Do you argue that mid-step releases would make the situation worse? Or would it just be "the same thing" ?
Ease of Development
I would personally welcome a mid step upgrade. I have ideas of things that COULD be tackled as "PINGS" though may break current modules. A midstep would allow an upgrade path and stability improvements. User interface improvements and growth from what has been learned while not throwing in a completed PONG. I think this would be a great step and help moving foreword in D8 development. I am not ignorant to the inherit problems with a PING, and I do not contribute to core, so the only thing I have to definitively add is my experience as a new module develope, a Drupal user, and a person who writes documentation, and provider of support.
I would hate to see D8 or a midstep come out so quickly that the current Drupal version (D7) modules do not become more widely available. I also do not comment on this to start another hot issue topic. We have had enough infighting and arguing, and the current, existing policy of Drupal has always been a PONG approach.
--Sig--
Owner of Proper Programming, LLC a software and website development firm.
Ease of Development
I would personally welcome a mid step upgrade. I have ideas of things that COULD be tackled as "PINGS" though may break current modules. A midstep would allow an upgrade path and stability improvements. User interface improvements and growth from what has been learned while not throwing in a completed PONG. I think this would be a great step and help moving foreword in D8 development. I am not ignorant to the inherit problems with a PING, and I do not contribute to core, so the only thing I have to definitively add is my experience as a new module develope, a Drupal user, and a person who writes documentation, and provider of support.
I would hate to see D8 or a midstep come out so quickly that the current Drupal version (D7) modules do not become more widely available. I also do not comment on this to start another hot issue topic. We have had enough infighting and arguing, and the current, existing policy of Drupal has always been a PONG approach.
--Sig--
Owner of Proper Programming, LLC a software and website development firm.
I think we are mixing up
I think we are mixing up "ping" and "pong" a bit.. maybe not the best choice terms?
Another way to say it would be "major release" and "mid step release".
A few situations where I would imagine this to be useful.
- Controversial, immature or never finished new features or usability improvements can be postponed to a mid-step-release.
- Valuable improvements, such as "Secure Password Hashes" can be backported to previous branches and released as mid-step.
- New hooks can be added in mid-step releases, to react to evolving needs in contrib.
- New features can be started in contrib to mature, and added back into core as a mid-step release (if this is ever desirable).
A question is about how we manage this with git:
Does everything need to go into the next "major" release, before it is backported to the "mid-step" one? Or do we not start the "major" one before we release the "mid-step" ? Or do we do this in parallel ? How hard would that be to merge later, now that we are on git?
This could kill the idea..
And, another question, what about version numbers? Would we need a new naming scheme?
Would we have more than one mid-step release, before the next major release?
yeah, ping sounds more likely
yeah, ping sounds more likely to be a minor release in comparison to the stronger pong.
besides that i really like this. maybe we can just have a 3-layered-versioning "x.y.z" where
x are major, api breaking releases
x.y are minor, feature releases
x.y.z are bug & security fix releases