[drupal-devel] How are patches to branches handled?
In Drupal, how are patches to branches handled? For example, there is a DRUPAL-4-5 tag, which was done when the repository was branched off for Drupal 4.5.0. Later, there was a DRUPAL-4-5-1, ...etc. Now, if someone finds a critical bug, that needs to be fixed in 4.5.1 for example, does it go to the daily build of 4.5.1? In other words, will the tar ball for 4.5.1 before the fix (e.g. Feb 1, 2005) differ from the 4.5.1 after the fix (e.g. Feb 2, 2005)? If we are doing this in Drupal, then there is a serious issue: the same release number can contain different code, which creates support issues: a person having the 4.5.1 from Feb 1 will say they have a problem, and another who has 4.5.1 from Feb 2 will say there is no problem. The obvious solution is that builds have to get a new number (e.g. 4.5.2) whenever fixes are made to a branch. Are we sure we are not falling into this trap? Of course, this does not apply to CVS HEAD, since by definition it is a dynamic moving target.
Op zaterdag 12 februari 2005 23:26, schreef K B:
Are we sure we are not falling into this trap?
AFAIK we are not. 4.5.1 contains the same code. 4.5.2 will be released as soon as enough important patches were committed to the 4.5 branch (not the 4.5.1 release). Regards, Bèr -- [ Bèr Kessels | Drupal services www.webschuur.com ]
What about modules, and fixes to branches? Some background: what prompted me to ask this question is Scott Courtney's message earlier today: === Good morning! A couple of days ago, I committed a one-line bug fix to the "weblink" module in CVS, with the DRUPAL-4-5 branch tag. I'm pretty sure it was committed successfully, because I see it here: http://cvs.drupal.org/viewcvs/drupal/contributions/modules/weblink/?only_wit... But it somehow didn't propagate to the main download version for Drupal 4.5, and doesn't show up here: http://cvs.drupal.org/viewcvs/drupal/contributions/modules/weblink/ What did I do wrong? ==== And some commits, for example, Dec 31 for image.module: http://drupal.org/cvs?file=/modules/image/image.module December 31, 2004 Commit #12482 by Goba Image: /modules/image/image.module 1.138 check for 'access images' permission on returning the block and the page link (ported from 4.5) Commit #12481 by Goba Image: /modules/image/image.module 1.132.2.3 @ DRUPAL-4-5 check for 'access images' permission on returning the block and the page link As you can see, there is a commit in the DRUPAL-4-5 branch. If the nightly build creats a 4.5.0, then we do have the problem I was fearing. On Sun, 13 Feb 2005 04:46:03 +0100, Bèr Kessels <berdrupal@tiscali.be> wrote:
Op zaterdag 12 februari 2005 23:26, schreef K B:
Are we sure we are not falling into this trap?
AFAIK we are not. 4.5.1 contains the same code. 4.5.2 will be released as soon as enough important patches were committed to the 4.5 branch (not the 4.5.1 release).
Regards, Bèr -- [ Bèr Kessels | Drupal services www.webschuur.com ]
Op zondag 13 februari 2005 04:55, schreef K B:
What about modules, and fixes to branches? contribs do not use the last digit. I.e. a contrib like image module has nothing to do with the 4.5.1 branch, it will only have a 4.5 branch.
Some background: what prompted me to ask this question is Scott Courtney's message earlier today:
Regards, Bèr -- [ Bèr Kessels | Drupal services www.webschuur.com ]
On Sun, 13 Feb 2005 05:01:33 +0100, Bèr Kessels <berdrupal@tiscali.be> wrote:
Op zondag 13 februari 2005 04:55, schreef K B:
What about modules, and fixes to branches? contribs do not use the last digit. I.e. a contrib like image module has nothing to do with the 4.5.1 branch, it will only have a 4.5 branch.
So what is the point of Scott and Goba (as examples, not to pick on anyone), fixing something in 4.5? Either: a) the fixes gets into 4.5.0, which means we have the problem we describe, or b) it does not, which brings to question the value of why the fix is done to the branch at all or c) I am missing something?
Some background: what prompted me to ask this question is Scott Courtney's message earlier today:
Regards, Bèr -- [ Bèr Kessels | Drupal services www.webschuur.com ]
What about modules, and fixes to branches?
contribs do not use the last digit. I.e. a contrib like image module has nothing to do with the 4.5.1 branch, it will only have a 4.5 branch.
So what is the point of Scott and Goba (as examples, not to pick on anyone), fixing something in 4.5? Either: a) the fixes gets into 4.5.0, which means we have the problem we describe, or b) it does not, which brings to question the value of why the fix is done to the branch at all or c) I am missing something?
With contrib modules the 4.5.0 version number does not mean that the module *is in* version 4.5.0, but that the module *is for* Drupal version 4.5.0. Contrib modules often change their code from day to day. There is no solution for this problem as of today AFAIK. Maybe project module could be updated to package new versions automatically into something like 4.5.0.20050212 (only when needed). Goba
On Sat, 12 Feb 2005, K B wrote:
On Sun, 13 Feb 2005 05:01:33 +0100, Bèr Kessels <berdrupal@tiscali.be> wrote:
Op zondag 13 februari 2005 04:55, schreef K B:
What about modules, and fixes to branches? contribs do not use the last digit. I.e. a contrib like image module has nothing to do with the 4.5.1 branch, it will only have a 4.5 branch.
So what is the point of Scott and Goba (as examples, not to pick on anyone), fixing something in 4.5? Either: a) the fixes gets into 4.5.0, which means we have the problem we describe,
This is true for all contrib modules and themes.
b) it does not, which brings to question the value of why the fix is done to the branch at all
For the main project these patches will be available in later releases, ie in 4.5.3 should it ever be created.
c) I am missing something?
Not anymore I hope. Cheers, Gerhard
OK, so my fears were true then. Is there any way to get over this problem? For example, using Goba's suggestion to tag the date/time to the build? Maybe a better solution is to keep the first two digits the same, then increment for every build. For example, we start at 4.5.0 with DRUPAL-4-5 as a tag, then have some fixes, then tag with DRUPAL-4-5-1 and make a build for 4.5.1 of that module/theme, then some more fixes, then 4.5.2, ...etc. This means applying the same standard for core Drupal to the contrib modules and themes. This way, when someone says he is using 4.5.0, then all other 4.5.0 would (hopefully) experience the same issue the first guy has. On Sun, 13 Feb 2005 12:12:50 +0100 (CET), Gerhard Killesreiter <killesreiter@physik.uni-freiburg.de> wrote:
On Sat, 12 Feb 2005, K B wrote:
On Sun, 13 Feb 2005 05:01:33 +0100, Bèr Kessels <berdrupal@tiscali.be> wrote:
Op zondag 13 februari 2005 04:55, schreef K B:
What about modules, and fixes to branches? contribs do not use the last digit. I.e. a contrib like image module has nothing to do with the 4.5.1 branch, it will only have a 4.5 branch.
So what is the point of Scott and Goba (as examples, not to pick on anyone), fixing something in 4.5? Either: a) the fixes gets into 4.5.0, which means we have the problem we describe,
This is true for all contrib modules and themes.
b) it does not, which brings to question the value of why the fix is done to the branch at all
For the main project these patches will be available in later releases, ie in 4.5.3 should it ever be created.
c) I am missing something?
Not anymore I hope.
Cheers, Gerhard
OK, so my fears were true then.
Is there any way to get over this problem? For example, using Goba's suggestion to tag the date/time to the build?
Maybe a better solution is to keep the first two digits the same, then increment for every build. For example, we start at 4.5.0 with DRUPAL-4-5 as a tag, then have some fixes, then tag with DRUPAL-4-5-1 and make a build for 4.5.1 of that module/theme, then some more fixes, then 4.5.2, ...etc.
This means applying the same standard for core Drupal to the contrib modules and themes.
This way, when someone says he is using 4.5.0, then all other 4.5.0 would (hopefully) experience the same issue the first guy has.
Entirely wrong way! You are free to install any of the 4.5.x contrib modules to any 4.5.x core setup. This is not going to be cleaner to support, if we are not going out of the scope of these three digits. The contrib module version should have a component indicating the compatibility of the module with drupal (currently only this is included), and another component, which signifies its own progress, so support can be easier, and the need for updates can be detected... Your above suggestion mixes the two, and therefore it is not acceptable IMHO. Goba
My assumption was that compatibility would be preserved between major releases. For example X.Y.something would be compatible with X.Y.somethingelse as long as X and Y are the same. So it is a 2 digit compatibility thing, not 3 digits. Right now, any 4.5.0 module can be installed with Drupal 4.5.0, 4.5.1 or 4.5.2 without any problem. The database is still the same, with no changes. This would still be preserved under my proposal, so: module A 4.5.1, module B 4.5.4 can also work with drupal 4.5.0. If Y changes, then all bets are off, and compatibility may be broken at the discretion of Drupal core developers and/or contrib developers. On Sun, 13 Feb 2005 18:34:21 +0000, Gabor Hojtsy <gabor@hojtsy.hu> wrote:
OK, so my fears were true then.
Is there any way to get over this problem? For example, using Goba's suggestion to tag the date/time to the build?
Maybe a better solution is to keep the first two digits the same, then increment for every build. For example, we start at 4.5.0 with DRUPAL-4-5 as a tag, then have some fixes, then tag with DRUPAL-4-5-1 and make a build for 4.5.1 of that module/theme, then some more fixes, then 4.5.2, ...etc.
This means applying the same standard for core Drupal to the contrib modules and themes.
This way, when someone says he is using 4.5.0, then all other 4.5.0 would (hopefully) experience the same issue the first guy has.
Entirely wrong way! You are free to install any of the 4.5.x contrib modules to any 4.5.x core setup. This is not going to be cleaner to support, if we are not going out of the scope of these three digits. The contrib module version should have a component indicating the compatibility of the module with drupal (currently only this is included), and another component, which signifies its own progress, so support can be easier, and the need for updates can be detected...
Your above suggestion mixes the two, and therefore it is not acceptable IMHO.
Goba
My assumption was that compatibility would be preserved between major releases.
For example X.Y.something would be compatible with X.Y.somethingelse as long as X and Y are the same.
So it is a 2 digit compatibility thing, not 3 digits.
Right now, any 4.5.0 module can be installed with Drupal 4.5.0, 4.5.1 or 4.5.2 without any problem. The database is still the same, with no changes.
This would still be preserved under my proposal, so: module A 4.5.1, module B 4.5.4 can also work with drupal 4.5.0.
If Y changes, then all bets are off, and compatibility may be broken at the discretion of Drupal core developers and/or contrib developers.
1. Contrib module maintainers do introduce compatibility breaking stuff in the same release cycle. 2. What do you imagine, would people pair a 4.5.2 contrib module with Drupal 4.5.2? Would they install a 4.5.2 contrib module on a 4.5.4 Drupal installation? I bet this would confuse the hell out of them. Goba
That was a suggestion on my part that would require more discussion. For example, we would have to live with the potential for confusion, and ask contributors not to break compatibility. Or we could live with the current problem as it is. Or we could have other proposals: anyone cares to propose them? On Sun, 13 Feb 2005 19:03:21 +0000, Gabor Hojtsy <gabor@hojtsy.hu> wrote:
My assumption was that compatibility would be preserved between major releases.
For example X.Y.something would be compatible with X.Y.somethingelse as long as X and Y are the same.
So it is a 2 digit compatibility thing, not 3 digits.
Right now, any 4.5.0 module can be installed with Drupal 4.5.0, 4.5.1 or 4.5.2 without any problem. The database is still the same, with no changes.
This would still be preserved under my proposal, so: module A 4.5.1, module B 4.5.4 can also work with drupal 4.5.0.
If Y changes, then all bets are off, and compatibility may be broken at the discretion of Drupal core developers and/or contrib developers.
1. Contrib module maintainers do introduce compatibility breaking stuff in the same release cycle.
2. What do you imagine, would people pair a 4.5.2 contrib module with Drupal 4.5.2? Would they install a 4.5.2 contrib module on a 4.5.4 Drupal installation? I bet this would confuse the hell out of them.
Goba
On Sun, 13 Feb 2005 14:05:08 -0500 K B <kbahey@gmail.com> wrote: [...]
Or we could have other proposals: anyone cares to propose them?
I would love to see some way to tag new versions of contrib modules. A large percentage of time-consuming (arguably time-wasting) support requests I get is because people are using an old 4.5 version of a given module. But how should they know that I merged in a whole string of fixes in the past week? Unless they know how to review CVS, there is no way for them to know. (Currently I have to get them to open the module file in a text editor and to look at the Id tag at the top of the file) What about using letters for modules? 4.5a, 4.5b, 4.5c. -Jeremy
Or we could have other proposals: anyone cares to propose them?
I would love to see some way to tag new versions of contrib modules. A large percentage of time-consuming (arguably time-wasting) support requests I get is because people are using an old 4.5 version of a given module. But how should they know that I merged in a whole string of fixes in the past week? Unless they know how to review CVS, there is no way for them to know. (Currently I have to get them to open the module file in a text editor and to look at the Id tag at the top of the file)
What about using letters for modules? 4.5a, 4.5b, 4.5c.
It has the potential of getting out of control, after reaching 4.5z (and given the long release cycle of Drupal itself, it could easily happen with an actively developed module). I suggested 4.5.x.20050213, because if contrib packages are made daily, this is clear, it can be automatically detected, if a new version should be shipped or not (whether there was CVS activity on the module or not on that day, or better worded: before the last release), and it has no way to run out of possibilities. If releases can only be made daily. IMHO it should help a lot, if these versions would be done automatically when needed, without human intervention. It also increases the possibility of shipping something broken though... Goba
On Sun, 13 Feb 2005 19:28:17 +0000 Gabor Hojtsy <gabor@hojtsy.hu> wrote: [..]
I suggested 4.5.x.20050213, because if contrib packages are made daily, this is clear, it can be automatically detected, if a new version should
That works perfectly for me, so long as a random user can quickly check the project page and see that a new release is available. -Jeremy
How about having just a number? 4.5.x.0, 4.5.x.1, ....etc? That can be set by a tag DRUPAL-4-5-0-0, DRUPAL-4-5-0-1 ...etc. If that is too tedious, then the date thing suggested by Gabor should be fine. The other aspect of the problem is how can someone tell which version of a module they have installed? It would be of great help if the admin/modules page (or a separate tab on that page) shows a release/version number next to each module. That number can be generated by the thing that creates the tar balls daily. It would have a version and a date in it, and someone can, at a glance. Of course, we cannot expect this page to show if the modules were locally changed or not, but at least we would know what the base version was. On Sun, 13 Feb 2005 19:28:17 +0000, Gabor Hojtsy <gabor@hojtsy.hu> wrote:
Or we could have other proposals: anyone cares to propose them?
I would love to see some way to tag new versions of contrib modules. A large percentage of time-consuming (arguably time-wasting) support requests I get is because people are using an old 4.5 version of a given module. But how should they know that I merged in a whole string of fixes in the past week? Unless they know how to review CVS, there is no way for them to know. (Currently I have to get them to open the module file in a text editor and to look at the Id tag at the top of the file)
What about using letters for modules? 4.5a, 4.5b, 4.5c.
It has the potential of getting out of control, after reaching 4.5z (and given the long release cycle of Drupal itself, it could easily happen with an actively developed module).
I suggested 4.5.x.20050213, because if contrib packages are made daily, this is clear, it can be automatically detected, if a new version should be shipped or not (whether there was CVS activity on the module or not on that day, or better worded: before the last release), and it has no way to run out of possibilities. If releases can only be made daily. IMHO it should help a lot, if these versions would be done automatically when needed, without human intervention. It also increases the possibility of shipping something broken though...
Goba
On 13-Feb-05, at 2:28 PM, Gabor Hojtsy wrote:
I suggested 4.5.x.20050213, because if contrib packages are made daily, this is clear, it can be automatically detected, if a new version should be shipped or not (whether there was CVS activity on the module or not on that day, or better worded: before the last release), and it has no way to run out of possibilities. If releases can only be made daily. IMHO it should help a lot, if these versions would be done automatically when needed, without human intervention. It also increases the possibility of shipping something broken though...
I think this is an important issue - as a module maintainer it would be much easier if a) users could visibly see that there had been a new module release for, say the 4.5 version, and b) if when trying to verify a bug i could say "what is the version / date of the module you're using" rather than having to say "open up foobar.module and find the cvs $Id$ tag at the top". One nitpick : I'm not sure the '.x.' is required, as we all know contrib is simply branched at DRUPAL-4-5 ... so I'd be infavour of foobar.module.4.5.20050217.tar.gz -j -- James Walker :: http://www.walkah.net/
On Saturday 12 February 2005 23:09, K B wrote:
So what is the point of Scott and Goba (as examples, not to pick on anyone), fixing something in 4.5?
I fixed the 4.5 branch rather than HEAD because, at present, I'm using a mix of 4.4 and 4.5 on my sites, and I'm developing for 4.5 at work. I know 4.6 is soon to be released, but my production sites won't upgrade immediately and will stay with 4.5 for a month or two. I don't yet have a HEAD test site running to play with, and don't have time right now to create it. (I know you weren't intending to pick on me, K.B., but you asked a reasonable question and I felt it deserved an answer.) Sorry my question stirred up this hornet's nest. I wasn't aware that the release process for a contributed module was that complicated, and I just assumed that I had done something wrong in my CVS commit. I didn't know that "project" was a downstream gatekeeper as well. Now I do, so no problem. :-) Scott -- -----------------------+------------------------------------------------------ Scott Courtney | "I don't mind Microsoft making money. I mind them scott@4th.com | having a bad operating system." -- Linus Torvalds http://4th.com/ | ("The Rebel Code," NY Times, 21 February 1999) | PGP Public Key at http://4th.com/keys/scott.pubkey
So what is the point of Scott and Goba (as examples, not to pick on anyone), fixing something in 4.5?
I fixed the 4.5 branch rather than HEAD because, at present, I'm using a mix of 4.4 and 4.5 on my sites, and I'm developing for 4.5 at work. I know 4.6 is soon to be released, but my production sites won't upgrade immediately and will stay with 4.5 for a month or two. I don't yet have a HEAD test site running to play with, and don't have time right now to create it.
(I know you weren't intending to pick on me, K.B., but you asked a reasonable question and I felt it deserved an answer.)
Sorry my question stirred up this hornet's nest. I wasn't aware that the release process for a contributed module was that complicated, and I just assumed that I had done something wrong in my CVS commit. I didn't know that "project" was a downstream gatekeeper as well. Now I do, so no problem. :-)
Don't be afraid, other contrib module maintainers often do such changes in their modules on previous branches. Mostly bugfixes on old branches, and feature improvements on the active branch (oftentimes not HEAD), because they have that stable version to work with, just like you. Goba
Gabor Hojtsy wrote:
Don't be afraid, other contrib module maintainers often do such changes in their modules on previous branches. Mostly bugfixes on old branches, and feature improvements on the active branch (oftentimes not HEAD), because they have that stable version to work with, just like you.
Part of the reason a Drupal code freeze takes up to a month or more, is to ensure that the most popular contributions get updated to work with the upcoming release. So if you maintain one or more modules, and if your schedule permits, this would be time to upgrade your modules. I'll create a DRUPAL-4-6 tag for the contributions repository shortly after I have announced the first Drupal 4.6.0 release candidate. Like that, maintainers can start branching their code when it is known to work with Drupal 4.6. -- Dries Buytaert :: http://www.buytaert.net/
participants (8)
-
Bèr Kessels -
Dries Buytaert -
Gabor Hojtsy -
Gerhard Killesreiter -
James Walker -
Jeremy Andrews -
K B -
Scott Courtney