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

[K B]

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