[drupal-devel] How are patches to branches handled?

[K B]

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 at 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
>