Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
By chx on
Proposal: the current core development cycle is releasing a stable (for example Drupal 5), opening up HEAD, hacking for N months and then releasing the next stable (Drupal 6) meanwhile 5.1, 5.2 etc gets released for bugfix. I propose that during the hacking period we do developer releases from time to time, maybe every two weeks, once there is something new that somewhat works. So there will be occassionally Drupal 6.x bugfix releases and more often Drupal 7.x unstable releases.
A few scenarios that might happen:
- Someone grabs a contrib module and try to update it. Currently it seems like a waste and impossible because HEAD is always changing. It still will be a waste somewhat because surely Drupal 8 (stable) and Drupal 7.3 (developer release) will be different API wise but not all effort is wasted and if some API does not work out for you, here is the chance to voice your concerns. The next "multistep node form" problem maybe won't need three releases to make easy...
- A consultant might want to do this because then she has a competitive edge -- honestly can tell her clients that she is already getting ready for Drupal 8. Currently noone can say that unless she is actually patching HEAD.
- A wise company might even set out a developer to port their custom modules because they have something to hold on. Again it's partially a wasted effort because API will change between 7.3 and 8 but, they might have a say in where the API will swing. A worthy investment.
- Once 7.3 is out, Dries can take a big patch and say, I commit this patch, and once HEAD is working again, I release 7.4. No other big patch gets in meanwhile. If said big patch is a big fluke, there is a point to easily roll back to. Other patches do not need to reroll daily, they can work with 7.3 constantly and when 7.4 is out, reroll then and only then.
Developer releases won't appear on the front page, nor on the download pages, only on http://drupal.org/node/3060/release. Garland page.tpl.php will contain a small header text, white on red saying "unstable release" so there is no mistake what it is.
So to sum up the advantages:
- Testable APIs
- Separated big changes
The disadvantages:
- Users might accidentally find it and think they should upgrade.
- We'll churn through major versions more quickly.
Comments
Lovely idea
I originally thought this would be a good idea back at http://drupal.org/node/85943 the last time I pushed through a change to the core version numbering scheme. ;) I'm glad we decided then on 2-digit numbers (which have proven to be quite a success). But, nothing stops us from taking the best of both worlds. To me, the big wins of doing this are:
A) Helps save effort for people who have to constantly re-roll patches against core. This is a huge problem. This change won't completely solve it, but it'll help.
B) Can facilitate people who want to operate in the "port early, port often" approach to their contribs. "Chasing HEAD" is a lot of work, but immensely valuable to the project over all. Nothing fleshes out API bugs and limitations like porting the big, complex contribs. This proposal on its own doesn't solve the human resources problem (not enough developers to port everything all the time) but it lowers the bar (since you have a fixed target to try porting to) and could help enable more early porting.
The only drawbacks are non-issues -- #1 is easily solved in the ways chx outlined above, and #2 is laughable.
Therefore, big +1 from me.
Thanks, chx!
-Derek
___________________
3281d Consulting
Even port rarely is better
Than what we have now, namely port never during the development cycle. As I often lament, those who write core, are (relatively) few -- they need to figure out every possible use. That's tedious and error prone, it'd be a lot better if those who actually use would try to do whatever they dream of with the new APIs.
I am writing this to clear my point: I do not want Views or CCK ported every two weeks. Well, I want, but then again, I want a billion dollars, too. I know I won't get either so no reason to yearn for it.
--
The news is Now Public | Drupal development: making the world better, one patch at a time. | A bedroom without a teddy is like a face without a smile. |
--
Drupal development: making the world better, one patch at a time. | A bedroom without a teddy is like a face without a smile.
I like this
So if I'm understanding this right, it would be possible for a dev version of a contrib module to say it works with a particular dev version of core? That would be handy if you were building a site and you wanted to stay with the cutting edge so you could easily see which pieces worked together. Well, as well as a totally unstable dev version works. :)
Michelle
--------------------------------------
See my Drupal articles and tutorials or come check out life in the Coulee Region.
Bleeding edge is a lonely place
There is no guarantee that you can update the database of such a website and security-wise you could be at a very dangerous place.
--
The news is Now Public | Drupal development: making the world better, one patch at a time. | A bedroom without a teddy is like a face without a smile. |
--
Drupal development: making the world better, one patch at a time. | A bedroom without a teddy is like a face without a smile.
I said building...
Building a site on a pre-release version is not the same as using it for your live site. :) But if you have a new website and you want to use the latest to build on (assuming you weren't going live until after release) and are willing to deal with potentially huge changes from "version" to version, then this would be handy.
Michelle
--------------------------------------
See my Drupal articles and tutorials or come check out life in the Coulee Region.
Also, reviews
We could set up a site with Drupal 7.3 and invite people to beat it. If noone else, then I will do that on https://www.nearlyfreespeech.net/ Doing this with HEAD makes a lot less sense because it's impossible to say which version of Drupal do they talk about.
--
The news is Now Public | Drupal development: making the world better, one patch at a time. | A bedroom without a teddy is like a face without a smile. |
--
Drupal development: making the world better, one patch at a time. | A bedroom without a teddy is like a face without a smile.
Remember the factoryjoe review of D6 beta
Those kind of things will become possible before the freeze with sites I described above.
--
The news is Now Public | Drupal development: making the world better, one patch at a time. | A bedroom without a teddy is like a face without a smile. |
--
Drupal development: making the world better, one patch at a time. | A bedroom without a teddy is like a face without a smile.
I am not convinced
What we need is to aim for more stability, not less.
Using even first stable releases is often impractical due to need to have the contrib modules up to speed. We are still trying to port everything from our 4.7 site to 5.3. I worry about even more unstable versions floating around and causing confusion for module developers and site maintainers. Bleeding edge experimentation is great but most people just need something that works.
This can be addressed if "developer" releases are noted as such so that no one is confused that they are for evaluation only. In that vein 7.3 is a terrible name for a developer release as it it implies stability - when we look at 5.3 side by side.
Maybe we should call these development "milestones" rather than releases and use third digit and "dev" suffix. This way 7.0.3-dev would mean 3rd development release of 7.x core. Then 7.1 would be the first stable 7.x, 7.2 next maintenance release, etc.
Why not multiple alpha
Why not multiple alpha releases?
No release announcement - just available from the tarball page like the -dev version currently is. The various Panels alpha releases (12? 13?) have made testing/reverting much easier, you'd still have milestones and afaik zero necessary changes to the current release system.
Anything to reduce the number of necessary re-rolls has to be worth looking at anyway.
I can not care less
Whether you call it Drupal 7 alpha 4 or simply Drupal 7.4. The only difference is that the first implies a Drupal 7 release, the second needs a Drupal 8. This is a minute difference.
--
The news is Now Public | Drupal development: making the world better, one patch at a time. | A bedroom without a teddy is like a face without a smile. |
--
Drupal development: making the world better, one patch at a time. | A bedroom without a teddy is like a face without a smile.
Yes of course. It's a minute
Yes of course. It's a minute difference in terms of how we think about it, but explicitly calling something 'alpha' rather than having stable - development - stable - development releases might cut down on people downloading things randomly. Either way I think this is a great idea.
Yes to alphas
It's an important distinction. Having 7.0, 7.1, etc. be released but "not for anyone but developers" until somewhere around 7.15 we finally say it's OK to release would be hellsa messy. However, a 7.x-alpha1, 7.x-alpha2, etc. every 2(?) weeks is obvious to anyone who knows anything about software development. That continues until they start getting called beta, which continues until they get called RC, which continues until they get called "for reals now".
On the flipside, though, I'd recommend against having an actual tag in project* for each alpha. The list would be ridiculously long very quickly. Keeping that at -dev only is probably OK. We'd still get most of the benefits of "milestone" dev releases. Alternatively, we can force-delete old alpha tags that are more than X releases old. I leave that to dww.
So +1 to alpha releases, -1 to naming them poorly. :-)
--
Larry Garfield
http://www.garfieldtech.com/blog
http://www.palantir.net
--
Larry Garfield
http://www.garfieldtech.com/
Thinking Functionally in PHP: https://leanpub.com/thinking-functionally-in-php
Releases must always have tags
No way you're going to convince me it's a good idea to not have tags for the official alpha releases. However, regarding your concerns, please read:
http://drupal.org/node/97568
http://drupal.org/node/112304
___________________
3281d Consulting
Chx, I love your line of
Chx, I love your line of thinking here.
From my standpoint, drupal releases have tended to follow these steps:
1. Madness
2. Code Freeze
3. More Madness -- sometimes with salty language
4. Dries gets cranky ( a cranky Dries says stuff like, "this is a new feature... we're in a freaking code freeze", or "Consider submitting this patch for the next release", or asking questions like, "Why does Drupal need this?")
5. A long debate on the dev email list ends with the development community agreeing on which disruptive changes they'll bet their life on.
6. More Madness
7. Panic
8. Code freeze [The sequel!]
9. Panic
10. Programmer sleepovers and such....
11. Beta 1 is released
Now I have said nothing of third party modules, not to mention businesses the that are basing their websites off of drupal core. With six, I'm advising our company to wait til version "1.0", and then will start the our journey towards the promised land of drupal six (don't for a second think I feel its not going to be worth it... i've been playing with six, and it delights me.)
What your suggesting, it seems, is something that resembles the way we deal with jQuery at my company. New jQuery version? We immediately upgrade. We can do this, because the changes are not so crazy sweeping, and *break everything* prone as drupal core changes.
I think what I like most about your ideas is that it suggests there is a better way of releasing a new drupal. It suggests "baby steps", as opposed to the "crush innocent citizens with your giant foot" gestures that I feel drupal releases are becoming (not because people are not doing a good job in the drupal community (all of you who contributed to 6 deserve a sterling badge of honor, and a star named after you).
ON Networks, for example has over 60000 lines of custom drupal modules, all of which will need updating. I really would like to be able to update them gradually -- like I update us to the newest jQuery, instead of in one grand, and bug-encouraging swoop.
I know the jQuery comparison isn't fair... -- javascript errors are a little less worse than php fatal errors.... but still... the gradual way we keep up with jQuery is not only good for our productivity... its good for our souls.
***
The reality is that our lil' drupal has outgrown the traditional drupal development process.
Either we can grow, or we can whither.
Chx: high five for drawing, and stepping into the "we need to grow, and evolve" line in the sand.
Cheers mate! I got your back (for what its worth.... if you run into trouble, I can "blog the shit" out of them... :-P )
--
"I'm not concerned about all hell breaking loose, but that a PART of hell will break loose... it'll be much harder to detect." - George Carlin
--
Personal: http://www.nicklewis.org
Work: http://www.onnetworks.com
--
"I'm not concerned about all hell breaking loose, but that a PART of hell will break loose... it'll be much harder to detect." - George Carlin
--
Personal: http://www.nicklewis.org
Work: http://www.zivtech.com
no objection from me. i
no objection from me. i would think that the person named as 'branch maintainer' for D7 would be the one responsible for issuing these releases.