[SM-Discuss] We don't wanna cast the broken things, do we?

Vlad Glagolev stealth at sourcemage.org
Sun Sep 7 18:27:48 EDT 2008


/me freezes test grimoire on his lappy for a few secs, lol.

OK, so it's time to solve this old problem.. With the current Robin's commits, sorry, I can't
close my eyes on this.

Though it was always a problem: forcing devel branches of the spells, where the stable versions
of them were pretty OK. Let's see: yes, there are few exceptions like libmikmod (3.2.0-beta2),
aalib (1.4rc5), libtheora (1.0beta3: yes, still beta) where "beta", "alpha", "rc", etc. -labels
are used. But that works only for the spells which -stable versions are out of date or even
dead.

Forcing the devel branches of software is a bad idea, really. If the original developer thinks
that his software is in alpha stage -- he marks it as alpha, rc for rc, and so on. Sorry, we
don't update linux kernel to 2.5, or python to 2.6/3.0 alpha/beta, or php. But! In php spell
we have that sweet DEVEL word in DETAILS. If a user wants to try out the devel version of it --
he chooses this branch and enjoys it. It's like it was done for many spells: wesnoth, dhcpcd,
alsa-* stuff, wine, and so on.

No, I'm not against Robin and his work, but I think it's incorrect.. uh.. let's say.. a bit.

Look at the kdelibs4's DETAILS (/me pets treeve, or who created such versioning system?) for
example. Stable, unstable, svn. PERFECT.

Prolly Treeve's not so lazy:
--
[01:47'32] CuZnDragon> I don't like maintaining the DEVEL versions.
--
j/k :)

I believe everyone knows about gnome's versioning policy: odd (e.g. 2.21) are devel, even (e.g.
2.22) are stable versions. Yes, sometimes it doesn't work for some gnome apps/libs (look at the
spell's history/offsite notes). But at least that works for glib2, gtk+2, gconf2 and atk :)

Oh, look. GTK+2 is a good example. Some of such updates from 2.x to 2.(x+1) cause API changes.
Please understand me and my words correctly :). I just don't wanna have some things broken on
`sorcery -g'. The problem comes if we force devel versions of software just before tagging
grimoire release. Sometimes it's not so good: no update from rc to stable before tagging the
release-of-the-month (grimoire) => epic fail. That's a bad practice.

Everyone knows that several of us use test grimoire in production to get the recent software
versions and to be up-to-date.. For some needs in new functionality of the software or security
reasons. Yes, sometimes we can't wait a month or more.

So test grimoire isn't a playground. And we shouldn't force the devel branches into it. That's
why do we have "devel?", "scm?", "svn?", "git?", "beta?", "old?" questions for our spells.
If a user wants to play with the devel versions -- he answers to such questions by "y" and
enjoys it.

We can create -devel branch of grimoire in the other hand.. but hey.. inventing the bicycle..
is.. ough.. :)

API changes. We have one current problem: libtool, yesterday 2.2.4 out, but 2.* out many weeks
ago. But! We still can't update it from 1.*, cause of.. yes.. AGAIN.. API changes. Lots of
spells will be b0rked after that update. So we need to update it carefully and check the every
spell (!). For me gtkam, libgphoto2 and hal are affected. And we're still staying at 1.*. So
it should be smooth update, not killing the people's work and nerves :)

For now I'll just revert the commits for atk and gconf2.

Hold me, thrill me, kiss me, kill me if you agree/disagree; this is an open discussion, and I
really wanna help to solve this problem/solve this problem with your help globally, here, in
SMGL :).

Thanks.

-- 
Dont wait to die to find paradise...
--
Cheerz,
Vlad "Enqlave" Glagolev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
Url : http://lists.ibiblio.org/pipermail/sm-discuss/attachments/20080908/cc6dea58/attachment.bin 


More information about the SM-Discuss mailing list