On Mon, Aug 30, 2004 at 12:00:14PM -0400, Brian Bockelman wrote:
> On Mon, 30 Aug 2004 09:21:40 -0400, Matthew Keller <kellermg@...> wrote:
> > On Mon, 2004-08-30 at 04:09, Ryan Barrett wrote:
> > > i'm sorry to say it, but me too. -1 to v84 style.
> > I just like it because it's simple and different. In my mind, v84 puts a
> > big middle-finger up at people who obsess over version numbers (oh no,
> > it's not 1.0 so it must suck. Oh no, it's ONLY 1.0 so this v2.0 over
> > here must be better, etc.).
> While I don't question the need to give the big middle-finger to
> people occaisonally, I don't think this would be one. I think going
> to a numbering system that means something significant to users would
> be useful. After all, v84 or v0.84 might mean that it's the 84
> release; but really - do you consider that knowledge relevant? Does
it is more representative of what we are doing now than saying 0.83 is,
and it also provides a better picture of the way things actually work in
gaim development, since we haven't had split code bases since the 0.59.x
days when we were migrating to 0.60.
> anyone think that knowing the release number is more important as
> knowing "this is the latest stable release"? I realize some people do
> compare version numbers unrealistically - aka, if Kopete is v2.0, then
> gaim at v1.0 must be worse - but that is NOT a good argument to deny
> the realistic users pertinent information.
its also not good to make them thing there is more info in the version
number than really is there.
> This example is going to be a bit rambling, but I feel is a textbook
> case for major.minor versioning.
> For example, let's say the lead developers put out some goals to work
> towards - the status rewrite, for example. I think all new major
something we have been VERY VERY bad about doing. just look at our
rather pitiful attempts at even creating a todo list.
> codework inherently has some bugs in it; if one would release a
> version with some major work in it as just v0.85, one might assume
> that it is MORE stable than v0.84. In reality, due to the major
> codework, it might be less stable. We have no way to mark this. So,
in reality, gaim hasn't had more than a handful of truely stable
releases since well before i joined the project, each release has had
some significant issues for at least a subset of users, though most
releases have worked acceptably well for most users. also in reality,
many of the releases we have gone into thinking it would be very stable
have had significant issues in use-cases we simply never hit.
> let's say some package managers/people realize this - some people are
> always going to be interested in stability over bleeding edge - and
> keep there distro on v0.84. If a big security hole is found, how does
yes, we have some users doing this already. and then they submit bug
reports and feature requests for things that they would have had fixed
and/or implemented if they had upgraded. this is particularly the case
with debian stable (shipping 0.59.x), mdk (shipping 0.75, a particularly
bad release), and fresh cd installs (which by very nature are out of
date with a project that releases even once a month).
> one address this? Do you release v0.86 to address this - if so, does
> the patch cover v0.84 or v0.85? If the release 0.86 patches the old
> codebase, then what the heck did you do that major coding in v0.85
> for? If you patch 0.85, you might leave most of your users (who are
> on 0.84) hanging in the wind. I release this project is a hobby, but
on the other hand, by forcing them to upgrade we stop hearing about
issues that have been solved for months. oh and did i mention that some
protocols, like yahoo of late, change and that the old versions simply
> forcing your users to upgrade from stable to unstable just to get a
> security patch is kind of rude.
i've always considered out job to get the new versions out the door, not
to maintain old versions. if you want to keep the same version and get
patches to it, look to someone with time to do that, like say your
> I would say at least a versioning system that allows for a
> development/stable version to be floating about would be desirable.
see the above for some hints as to why differentiating a "development"
and a "stable" version are bad.
> This allows for people who want all the bleeding-edge features to have
> a version of gaim, and for people who want stability and
> no-breakage-no-matter-what to have their version of gaim.
as mentioned above, the changing nature of the protocols will ENSURE
that your "no-breakage-no-matter-what" version WILL break. lets take a
look here: yahoo won't work older than 0.79. msn won't work older than
0.69. gadu-gadu has changed the protocol sometime in the last 4 versions
(forget exactly when), several years ago you HAD to use cvs to stay
connected to aim (that only lasted for a few months). any of these
events can and probly will happen again.
in summary, the biggest issues i see are:
1)maintaining old versions takes time and effort. who is going to do
this? and more importantly when? given time and ability to backport the
fixes and patches, i _can_ make the requisite changes to the bug
tracking to support that side of things. though doing so would be
considerably easier in a better tracker than sf provides, but i'm probly
not the one to try to keep those old versions patched.
2)what makes a release stable? i would argue that _at most_ two releases
since 0.60 would qualify. and that only if you carefuly match that code
against the "right" version of gtk. NO win32 release would qualify as
stable. CERTAINLY "stable" on unix and win32 would and will continue to
3)how do we publish a roadmap when things like status get delayed
indefinitally, and the stuff going into new versions, some of it very
significant, are things we wake up one morning and code, or find a patch
for in our inboxes?
> Just my thoughts,
> Brian B