guile-gtk-general
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: New arch branch: mainline


From: Andreas Rottmann
Subject: Re: New arch branch: mainline
Date: Thu, 01 Jan 2004 21:01:14 +0100
User-agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3 (gnu/linux)

Rob Browning <address@hidden> writes:

> Andreas Rottmann <address@hidden> writes:
>
>> The API breaking changes (mainly dynamic wrappers and GOOPS support)
>> are only in the --rotty--0.2 branch now. Until I hear a comment from
>> Rob wrt to his release plans, I will continue to make the more
>> invasive changes to this branch. If Rob stays silent, I seriously
>> consider starting an unstable release series (named something like
>> g-wrap-1.5.X, perhaps with an -rotty suffix). Wingo, what do you
>> think?
>>
>> [0] http://stud3.tuwien.ac.at/~e9926584/arch/2003-main
>
> FWIW I'm back, and I've finished restoring my access to savannah now
> that it's back too.  If all goes to plan, I'll be spending much of
> tomorrow catching up on g-wrap and guile related work (now that the
> holiday distractions are more or less over).
>
Fine! Nice to see you speak up again.

> I agree that bug-fixes releases for 1.3.X are a good idea, and I may
> focus on your changes there first.  If I recall right, we also still
> need to figure out the guile version soname issues, but I need to look
> back at our last exchange.  In any case, I still don't have a good
> grasp on arch so that I can interact with your repository, but that's
> first on my list for tomorrow.
>
> BTW, why 1.5.X rather than 1.4 (or 1.6) for the next major release?
>
'Cause the first releases on the 1.5 series are to be considered part
of an unstable release series (like Linux 2.5.X). The next major
release would then be 1.6.0, for which we could consider the following
features as release goals:

1) libffi support (mostly done, needs a bit of tweaking wrt thread-safeness)
2) CSE support
3) rewrite to g-wrap internally to use GOOPS

For 1.3, we maybe what would be 1.3.5 should release as 1.4.0, so we
consistently use the linux versioning scheme starting with 1.4.0.

> I'd be tempted to switch to the linux kernel versioning scheme
> unless we have a good reason not to.
>
Agreed.

> Though depending on just how different the next major release is, it
> might even be worth considering a bump to the major number, i.e. a
> 2.0.X designation.
>
Yes, I think the items 2 and 3) above would well make the changes
worth a major number bump IMHO.

Regards, Andy
-- 
Andreas Rottmann         | address@hidden      | address@hidden | address@hidden
http://yi.org/rotty      | GnuPG Key: http://yi.org/rotty/gpg.asc
Fingerprint              | DFB4 4EB4 78A4 5EEE 6219  F228 F92F CFC5 01FD 5B62

Python is executable pseudocode, Perl is executable line-noise.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]