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

Re: Development/Production versions (was RE: CVS)





--- robby <robby@cs.rice.edu> wrote:
> >
> >Great news to learn that the CVS repository for PLT Scheme products
> is
> >available and that the precise GC is nearing its completion.
> >
> >With regard to new and cool but rather complicated features it might
> >have sense to maintain two code collections like Linux does:
> >* Stable tree (even version numbers), only bug fixes are accepted
> >* Development tree (odd version numbers).
> >Current version numbers like "102/8" do not provide a clear cut
> along
> >stability line.
> 
> Generally speaking, we try to make each external release as stable as
> 
> we can and  the internal releases may be a little bit less stable, 
> but for the last two years I have been using the internal release 
> exclusively for my day to day drscheme needs.
> 
> We do not need as complicated a setup as linux since we only have 
> about 5 active developers and 4 of them are within 100 feet of each 
> other.
> 
> Robby

Good news to know that there is a mighty handful team developing PLT
Scheme. It looks as PLT Scheme is the most rapidly evolving Scheme
implementation as of now!
Here is a question: current MzScheme release is 101. 
Let say, somebody found a bug and a bug has been promptly fixed. 
What will be the bug-fix version: 102  or 101/9 ?
and how I destinguish a bug-fix version from the major release?
Another practical question: how would I know when to upgrade my 
MzScheme-101 to incorporate latest bug fixes?

Conventional versioning scheme is pretty simple and works fine 
for many projects and is a three-part hierarchy:
     major_number.minor_number.fix_number (like 2.2.5)
where major_number is usually incremented when major changes to
functionality occur (like OO system), minor_number represents less
drastic changes still  visible to a user (new GC), and fix_number is
for bug fixers and some internal implementation changes. It is really
not that complicated after all.
Projects of the scale of PLT Scheme usually have two lines of
development: one targeted towards the new features and 
new functuanality, the other being bug fixes to existing released
versions.
I agree that for developers who are within 100  feet of each other any
versioning scheme will work. But for those of us that are thousands of
miles from Texas some more conventional and uniform method will be
helpful. 

thanks,
--Leo


__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com