[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
On March 25, 2010, Evert Glebbeek wrote:
> On 25 Mar 2010, at 6:15 , Thomas Fjellstrom wrote:
> > And on the subject of releases, should the monthly release schedule be
> > kept up for minor releases?
>
> Maybe, yes.
>
> > And what constitutes a good enough reason to
> > increment the major (ie the x in 5.x) version?
>
> Good question. With 4.0/4.2 this was clear: 4.0 was bugfixes only, new
> features/platforms was 4.2.
>
> > Can allegro try a new major version (5.2,5.4, etc) every 6 months
> > regardless if theres an actual major change?[1]
>
> I don't know, not sure if I like that idea. It seems pointless and leads
> to a rather quick inflation in version number. Also depends on what our
> policy is for when the number gets incremented, but "6 months have
> passed" is not a good criterion.
Well a monthly release leads to a quick increase in the version number. Look
at the current wip, 4.9.19, I can imagine we may see a 5.0.24.
> Remember that 5.2 and 5.0 are not meant
> to be ABI compatible, which can be annoying (I don't update every time
> there is a release, certainly not if they are frequent and changes are
> small).
If a time based release schedule is agreed upon, it would pretty much change
what the version means. What other projects do when they move to this type
of schedule is either use date based versions, or simplify the version
number, ie: instead of 5.x being the major version, it moves to just x, and
the minor releases are after the decimal, so each monthly release would be
5.1, 5.2, etc, and the half yearly, or ABI change release would bump the
real major number. So ABI changes would give us Allegro 6.x, and the next
abi change would give us Allegro 7.x.
The only real concern I have is it would make the version number more
meaningless, like it has done with many other projects. Not that thats
really a bad thing. Version numbers were mostly meaningless to begin with.
I'm not sure whats worse, inflating the major and minor number, or keeping
with the current setup with 4.9.19.1 style versions.
To be honest, I don't think it REALLY matters, version numbers are fairly
meaningless.
> > And a new incremental (5.x.n) every
> > month, or every two months?
>
> That could work.
>
> > Constant and regular releases does seem to affect the overall health of
> > opensource projects. I think it has to do with perception more than
> > anything, the project doesn't seem dead, so people are more willing to
> > give it a shot.
>
> True, but I never actually look at the version number, just at the date
> for the last release. So incrementing the minor number would be fine for
> that.
Might turn into the linux kernel that way, 5.0 forever! (or 2.6 forever!)
Imagine a 5.0.33 release ;D
So the only real reason to increment the "major" version is when the ABI
needs to break (ie: removing things). I can't recall a time when that
actually happened in allegro, things were just added most of the time.
> Evert
>
--
Thomas Fjellstrom
tfjellstrom@xxxxxxxxxx