Public SourceMage Discussion List

[Vlad Glagolev <stealth AT sourcemage.org>]

/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

Attachment: pgpj2xTXETqbt.pgp
Description: PGP signature