[drupal-devel] How are patches to branches handled?
kbahey at gmail.com
Sun Feb 13 20:11:41 UTC 2005
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
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...
More information about the drupal-devel