RE: [infrastructure] Re: [development] Drupal 4.5 unsupported
-----Original Message----- From: development-bounces@drupal.org [mailto:development-bounces@drupal.org] On Behalf Of Larry Garfield Sent: Tuesday, May 30, 2006 10:48 AM To: development@drupal.org Subject: Re: [infrastructure] Re: [development] Drupal 4.5 unsupported
On Tue, May 30, 2006 8:59 am, Khalid B said:
On 5/30/06, blogdiva@culturekitchen.com <blogdiva@culturekitchen.com> wrote:
That's an awesome question. I'd like to hear from developers and the people in the marketing team. The question is at the core of what I feel Drupal is overlooking at the moment --code freezes.
Code freezes do happen. Once we have a release, its API does not change (may be a tiny bit occasionally, but not normally).
What we do not freeze is APIs between releases. How can we move forward from 4.7 to 6.6 with the API remaining the same? Where would the new stuff go? Are you advocating we keep APIs forever?
Read my comment here on where the energy should be focussed (migration tools, transitional releases, and compatibility layers).
Honestly, I think part of the issue with the "stable API" question is that Drupal uses version numbers differently from many projects. The de facto standard for version numbers for most projects is Major.Minor.Bug / x.y.z.
Z increases only fix bugs. Y increases add features, but don't break backward compatibility with 3rd party code. X increases, all bets are off.
Witness, for instance, KDE, which has evolved and improved dramatically in the 3.y.z cycle, but code for 3.0.0 still (generally) works in 3.5.1. For the upcoming 4.0, howver, there are no "sacred cows" and everything will need to be updated.
For Drupal, Y increases, all bets are off. We technically don't have Y releases, just Z and X, but we use both of the first two numbers for the X releases. That throws a lot of people off. It actually surprised me a great deal, although fortunately it didn't affect my plans significantly.
Whatever else we do, we should probably make that clearer right up front. It's not inherently a bad development model, just an unconventional one that needs to be made clearer.
--Larry Garfield
How much more clear can I make this? http://drupal.org/handbook/version-info The alias is recent but it has been at the top level of the handbook now for about a year. Should we link it in the Project download page for Drupal? There are other projects that use different from KDE versioning release scheme's as well. Drupal's been consistent for the 3 years I've used it with it's versioning information and method. The versioning scheme has not changed at all. -sp
On Wed, May 31, 2006 1:31 pm, Steven Peck said:
For Drupal, Y increases, all bets are off. We technically don't have Y releases, just Z and X, but we use both of the first two numbers for the X releases. That throws a lot of people off. It actually surprised me a great deal, although fortunately it didn't affect my plans significantly.
Whatever else we do, we should probably make that clearer right up front. It's not inherently a bad development model, just an unconventional one that needs to be made clearer.
--Larry Garfield
How much more clear can I make this? http://drupal.org/handbook/version-info The alias is recent but it has been at the top level of the handbook now for about a year. Should we link it in the Project download page for Drupal?
Absolutely! People should not be able to download anything from Drupal.org without having that page offered to them, at least as a clear and prominent link. I do have some suggestions to make the page clearer, but I'm at work at the moment so will have to get back to you on that later. Stay tuned. :-)
There are other projects that use different from KDE versioning release scheme's as well. Drupal's been consistent for the 3 years I've used it with it's versioning information and method. The versioning scheme has not changed at all.
-sp
Once again, I'm not saying the Drupal versioning system is bad, just not the normal treatment of X.Y.Z that people have been trained to expect. I use KDE only as a high-profile example. It's easier to change people's perceptions and expectations (see comment above) than to completely change our development model. So let's make sure we do a good job of that. :-) --Larry Garfield
Larry Garfield wrote:
On Wed, May 31, 2006 1:31 pm, Steven Peck said: Once again, I'm not saying the Drupal versioning system is bad, just not the normal treatment of X.Y.Z that people have been trained to expect. I use KDE only as a high-profile example.
If we change the versioning system at all, our versions should converge against an irrational number as TeX does. Unfortunately, pi is taken and we are past e. Any suggestions? Cheers, Gerhard
On 5/31/06, Gerhard Killesreiter <gerhard@killesreiter.de> wrote:
Larry Garfield wrote:
On Wed, May 31, 2006 1:31 pm, Steven Peck said: Once again, I'm not saying the Drupal versioning system is bad, just not the normal treatment of X.Y.Z that people have been trained to expect. I use KDE only as a high-profile example.
If we change the versioning system at all, our versions should converge against an irrational number as TeX does. Unfortunately, pi is taken and we are past e. Any suggestions?
Simple: if we break the current API, the next release from HEAD is 5.0.0. If we don't, then it is 4.8.0
On 31 May 2006, at 11:32 PM, Khalid B wrote:
Simple: if we break the current API, the next release from HEAD is 5.0.0. If we don't, then it is 4.8.0 Seriously. I don't think that is going to change a single thing about how we develop.
All that will happen is we will go to drupal 23.y.z much quicker, and means we will almost never increment y. How we number it won't change the fact that your code might not work on the next release, because we have found a better/cleaner way to do something, or have perhaps introduced new functionality which makes your code obsolete. or whatever. I don't see that this 'mythical' stable api is anywhere near accomplishable, as Drupal is moving too fast, in too many directions, to even consider it. To me : x = major architectural changes, in the form of major overhauls of existing systems, or powerful new systems being introduced. (4.x : node, taxonomy etc , 5.x : cck, views, perhaps some action / workflow stuff, 6.x: sentience and self-awareness ? ) y = api changes z = bug fixes -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com
Inline below... On 5/31/06 2:53 PM, "Adrian Rossouw" <adrian@bryght.com> wrote:
On 31 May 2006, at 11:32 PM, Khalid B wrote:
Simple: if we break the current API, the next release from HEAD is 5.0.0. If we don't, then it is 4.8.0 Seriously. I don't think that is going to change a single thing about how we develop. To me : x = major architectural changes, in the form of major overhauls of existing systems, or powerful new systems being introduced. (4.x : node, taxonomy etc , 5.x : cck, views, perhaps some action / workflow stuff, 6.x: sentience and self-awareness ? ) y = api changes z = bug fixes
Another thread I have to jump in on. What is the desired outcome of this thread by the original poster? The answer: to make sure the naming convention is clear and consistent. As Speck said, it's been the same for the last 3 years. So given the desired outcome (stability, clarity), how would changing *anything* after three years of stable naming convention produce anything but a lose-lose for everyone involved. As Adrian pointed out (and it's a good point!), it wouldn't "change a single thing" for development. How would changing a three year old convention help make things more clear and consistent, if the convention itself is already consistent. Nay! (I love that word) The answer here is merely to make the convention more clear (aka, documented), not to change anything if the goal truly is as stated. The first rule of development is not to fix it if it isn't broke. This ain't broke. So there is no reason to fix it. It might need to be explained a little better, and it might be cool if version releases had some explanation to how the number was arrived at on the homepage of drupal.org (for those who are interested) when releases are posted (or in the release notes, where, wait! It's already in there!), but beyond that, I can only see a lose-lose for the requestors on the thread, and for the developers who have to start thinking about something that really has minor value. Think of it this way... What information can you derive from version release numbers. Minor releases can break sites. Bug fixes and break sites. API Changes can break sites. Major architecture changes WILL break sites. Only one of these version numbers is guaranteed to break crap when it changes. But ALL of them are capable of breaking stuff. That's what version release notes are for (you do read them before upgrading right?). So the version number is largely semantic anyways - it merely indicates a risk level, but the risk is always there anyways, and you should be doing the legwork before installing, or reading the associated post with the release, or reading at a minimum the release docs in the package, all of which cover the information (in more depth) contained in the release number _anyways_ so what is the point here? I think Adrian's system here makes tons of sense. But I don't think there is any value in changing release numbers - from a material, site management point of view all of the information needed to upgrade should be in the release notes, including errata and potential site breaking bits. If anything, we should be harping on making better (more consistent, more readable) release notes, not changing version numbers that have been consistent for three years. It's a mere mental game imho. And changing it would actually denigrate the stability and clarity of three years of release management - where is the sense in that?! Jonathan
So pardon my ignorance, but what would be a big enough change to constitute a incrementing X under the current versioning system? I wasn't around for the last changes to that X version number, so I wouldn't know. On 5/31/06, Jonathan Lambert <j@firebright.com> wrote:
Inline below...
On 5/31/06 2:53 PM, "Adrian Rossouw" <adrian@bryght.com> wrote:
On 31 May 2006, at 11:32 PM, Khalid B wrote:
Simple: if we break the current API, the next release from HEAD is 5.0.0. If we don't, then it is 4.8.0 Seriously. I don't think that is going to change a single thing about how we develop. To me : x = major architectural changes, in the form of major overhauls of existing systems, or powerful new systems being introduced. (4.x : node, taxonomy etc , 5.x : cck, views, perhaps some action / workflow stuff, 6.x: sentience and self-awareness ? ) y = api changes z = bug fixes
Another thread I have to jump in on. What is the desired outcome of this thread by the original poster? The answer: to make sure the naming convention is clear and consistent.
As Speck said, it's been the same for the last 3 years. So given the desired outcome (stability, clarity), how would changing *anything* after three years of stable naming convention produce anything but a lose-lose for everyone involved. As Adrian pointed out (and it's a good point!), it wouldn't "change a single thing" for development.
How would changing a three year old convention help make things more clear and consistent, if the convention itself is already consistent.
Nay! (I love that word) The answer here is merely to make the convention more clear (aka, documented), not to change anything if the goal truly is as stated.
The first rule of development is not to fix it if it isn't broke. This ain't broke. So there is no reason to fix it. It might need to be explained a little better, and it might be cool if version releases had some explanation to how the number was arrived at on the homepage of drupal.org (for those who are interested) when releases are posted (or in the release notes, where, wait! It's already in there!), but beyond that, I can only see a lose-lose for the requestors on the thread, and for the developers who have to start thinking about something that really has minor value.
Think of it this way... What information can you derive from version release numbers. Minor releases can break sites. Bug fixes and break sites. API Changes can break sites. Major architecture changes WILL break sites. Only one of these version numbers is guaranteed to break crap when it changes. But ALL of them are capable of breaking stuff. That's what version release notes are for (you do read them before upgrading right?). So the version number is largely semantic anyways - it merely indicates a risk level, but the risk is always there anyways, and you should be doing the legwork before installing, or reading the associated post with the release, or reading at a minimum the release docs in the package, all of which cover the information (in more depth) contained in the release number _anyways_ so what is the point here?
I think Adrian's system here makes tons of sense.
But I don't think there is any value in changing release numbers - from a material, site management point of view all of the information needed to upgrade should be in the release notes, including errata and potential site breaking bits. If anything, we should be harping on making better (more consistent, more readable) release notes, not changing version numbers that have been consistent for three years. It's a mere mental game imho. And changing it would actually denigrate the stability and clarity of three years of release management - where is the sense in that?!
Jonathan
Another thread I have to jump in on. What is the desired outcome of this thread by the original poster? The answer: to make sure the naming convention is clear and consistent.
As Speck said, it's been the same for the last 3 years. So given the desired outcome (stability, clarity), how would changing *anything* after three years of stable naming convention produce anything but a lose-lose for everyone involved. As Adrian pointed out (and it's a good point!), it wouldn't "change a single thing" for development.
I am not hungup on moving to A naming scheme because other projects use it. Granted, a more widely used scheme has a better chance of being understood vs a more obscure one. However, it seems that the current scheme is not communicated well. Or is communicated, but the message failed to reach the intended audience. So, how do we make it more easy to find/communicate or use a scheme that has a better chance of being understood?
On 5/31/06 4:22 PM, "Khalid B" <kb@2bits.com> wrote:
So, how do we make it more easy to find/communicate or use a scheme that has a better chance of being understood?
I think that's the million dollar point. I think this is the page on the site that references the subject: http://drupal.org/handbook/version-info Is that documentation clean enough? If not, let me know how you would like it updated (seriously, folks, weigh in here, this is the actual resolution to this issue) and I will accumulate the results and get it updated nicely. Coo? Jonathan --
On 01 Jun 2006, at 01:22, Khalid B wrote:
As Speck said, it's been the same for the last 3 years. So given the desired outcome (stability, clarity), how would changing *anything* after three years of stable naming convention produce anything but a lose-lose for everyone involved. As Adrian pointed out (and it's a good point!), it wouldn't "change a single thing" for development.
I am not hungup on moving to A naming scheme because other projects use it. Granted, a more widely used scheme has a better chance of being understood vs a more obscure one.
Depends on who you are comparing with. The Linux kernel project, to name one, is the biggest open source project in existence, and uses our versioning scheme. We're not going to change our version system. -- Dries Buytaert :: http://www.buytaert.net/
I am not hungup on moving to A naming scheme because other projects use it. Granted, a more widely used scheme has a better chance of being understood vs a more obscure one.
Depends on who you are comparing with. The Linux kernel project, to name one, is the biggest open source project in existence, and uses our versioning scheme.
But ... there is a big difference ... End users do not "use" the kernel directly. They use distributions. All the kernel does is support A and B hardware. Drupal on the other hand is usable as it is in the version. If Drupal was just a code API, and given to others to make distros (like CivicSpace, Sympal), then the Drupal version number would be irrelevant to the end users, since the audience for Drupal are developers only, and we can be cryptic as much . But, Drupal is also usable by end users directly, and hence the confusion.
We're not going to change our version system.
I guess that is the tie breaker then. We are left with only improving how we communicate it.
On 01 Jun 2006, at 15:18, Khalid B wrote:
Depends on who you are comparing with. The Linux kernel project, to name one, is the biggest open source project in existence, and uses our versioning scheme.
But ... there is a big difference ...
End users do not "use" the kernel directly. They use distributions. All the kernel does is support A and B hardware.
This discussion is pretty moot for reasons explained by others. The Linux kernel is just one example -- and just like Drupal, they haven't bumped their major version number in years. Where are all the confused Linux users? (Yes, I periodically recompile my kernel in order to keep up to date, the fix security issues, etc.) MacOS X is another example: they had 10.0, 10.1, 10.2, 10.3 and 10.4. It's used and understood by millions of people, and APIs break from one 10.x release to another. Firefox is another example. The current release is 1.5.0 and the modules and extensions are not compatible with those of Firefox 1.0.x. According to your rules, they should have gone straight to 2.0.0. Where are all the confused Firefox users? -- Dries Buytaert :: http://www.buytaert.net/
If we change the versioning system at all, our versions should converge against an irrational number as TeX does. Unfortunately, pi is taken and we are past e. Any suggestions? Inf? NaN?
If it was up to me I would consitently looseobvious the order of release 'numbers'. This way people would not consider moaning about it, just accept it as an eccentric fact of life. The truth is that the OSS development model naturally disambiguates any version numbering. In drupal's case the only hard meaning number is the third one - it is a bugfix release, no api changes. The rest is too vague, and you really need to dive into the development history, get PhDs in OSS archeology and psychology and form a theory. Which might reflect a portion of the truth. Drupal 5.x.x will probably come when it feels right, to whoever is around at the time. And that is the most precise definition. You will find various other explanations around that time as well, but the main reason will still be it looks like 5, feels like 5, so it is 5. It is duck versioning :)
On 5/31/06, Gerhard Killesreiter <gerhard@killesreiter.de> wrote:
If we change the versioning system at all, our versions should converge against an irrational number as TeX does. Unfortunately, pi is taken and we are past e. Any suggestions?
i (the imaginary number) seems like a good choice, as we strive towards the perfect cms. failing that, we should at least rehash the thread about giving the releases silly names. - Alan
failing that, we should at least rehash the thread about giving the releases silly names.
That is a separate discussion. It will only help defer putting a number on the next version and using a code name instead. So, whether something is 6.5.0 or 7.0.0 can be determined late in the release cycle not in the beginning which (IMHO) is a good thing since we do not know what features will be in until the freeze takes effect. Once that version is released, it has to take a number and we are back to this dicussion. In any case, Dries said he will not change the versioning scheme, so the only option left is to a) improve Steven Peck's document and b) communicate it better.
On Thu, June 1, 2006 9:22 am, Khalid B said:
failing that, we should at least rehash the thread about giving the releases silly names.
That is a separate discussion. It will only help defer putting a number on the next version and using a code name instead. So, whether something is 6.5.0 or 7.0.0 can be determined late in the release cycle not in the beginning which (IMHO) is a good thing since we do not know what features will be in until the freeze takes effect.
Once that version is released, it has to take a number and we are back to this dicussion.
Unless you go the full Ubuntu route, in which case the version we just released is Drupal 6.05 "Greasy Gander". :-) --Larry Garfield
Larry Garfield wrote:
Once again, I'm not saying the Drupal versioning system is bad, just not the normal treatment of X.Y.Z that people have been trained to expect. I use KDE only as a high-profile example. It's easier to change people's perceptions and expectations (see comment above) than to completely change our development model. So let's make sure we do a good job of that. :-)
Larry, I would bet that if we would have named Drupal 4.7.0 as Drupal 5.0.0 instead, people would expect drastic user level changes (UI, workflow, etc). The whole versioning discussion ended up because supposed *users* are mislead by our versioning scheme. As long as there are only internal changes and not much UI changes, I don't think a *user* would see the big version increment fitting. Gabor
On Thu, June 1, 2006 1:52 am, Gabor Hojtsy said:
Larry Garfield wrote:
Once again, I'm not saying the Drupal versioning system is bad, just not the normal treatment of X.Y.Z that people have been trained to expect. I use KDE only as a high-profile example. It's easier to change people's perceptions and expectations (see comment above) than to completely change our development model. So let's make sure we do a good job of that. :-)
Larry, I would bet that if we would have named Drupal 4.7.0 as Drupal 5.0.0 instead, people would expect drastic user level changes (UI, workflow, etc). The whole versioning discussion ended up because supposed *users* are mislead by our versioning scheme. As long as there are only internal changes and not much UI changes, I don't think a *user* would see the big version increment fitting.
Gabor
<sigh> How many times can I say this. I am not suggesting we change Drupal's versioning system. I repeat: I am not suggesting we change Drupal's versioning system. I say again: I am NOT suggesting we change Drupal's versioning system! Next person who misinterprets me as suggesting we should change our versioning system gets a banana cream pie in the face. </rant> I am saying we need to do a better job of explaining what our versioning system means. It should not be possible to download code from Drupal.org without having a version compatibility page presented to you, at the very least as a clearly (and enticingly) labeled link. I talked with sepeck last night about our version documentation, and ended up getting drafted to take a crack at revising it again. :-) I'll be doing so as soon as I get a chance to sit down and work on it, hopefully in the next few days. --Larry Garfield
Next person who misinterprets me as suggesting we should change our versioning system gets a banana cream pie in the face. </rant>
Does it taste good? Larry says Version change ... Just the troll in me. Couldn'd resist :-)
There's nothing wrong with Drupal's versioning system. If you used the KDE "standard" you'd be around version 16 or so by now. But most people expect what Steven suggested so people are misled by their expectations...and they have no real reason to expect something else. You DON'T have to change it. You DO have to expect the same confusion every version change as the user (NOT the developer) community grows. Not that there hasn't been enough discussion and plans laid to cover every complaint made in the last few days. You ARE addressing upgrades through the install system. There's been discussion of core vs verified vs "Wild West" contributions. You're working on install profiles, which will also be maintained via update.php, I guess. What else...being nice to end users? Does anyone REALLY need advice on how that's done? That's my biweekly contribution to non-coding subjects. On 5/31/06, Steven Peck <speck@blkmtn.org> wrote:
There are other projects that use different from KDE versioning release scheme's as well. Drupal's been consistent for the 3 years I've used it with it's versioning information and method. The versioning scheme has not changed at all.
-sp
participants (12)
-
Adrian Rossouw -
Alan Dixon -
Corey Bordelon -
Dries Buytaert -
Earl Dunovant -
Gabor Hojtsy -
Gerhard Killesreiter -
Jonathan Lambert -
Khalid B -
Larry Garfield -
Steven Peck -
Vladimir Zlatanov