avr-libc-dev
[Top][All Lists]
Advanced

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

Re: [avr-libc-dev] [RFC] 1.0 branch


From: Theodore A. Roth
Subject: Re: [avr-libc-dev] [RFC] 1.0 branch
Date: Tue, 12 Aug 2003 08:54:47 -0700 (PDT)


On Tue, 12 Aug 2003, Joerg Wunsch wrote:

> As Theodore A. Roth wrote:
>
> > Since things have been quiet for a while, I think it might be time to
> > cut a 1.0 branch.
>
> Good idea.  So let's finally ship something that is marked `release'
> again.
>
> > I'm partial to the even-odd version number used with the linux kernel
> > and many other projects. Basically, <major>.<minor>.<patch>, where
> > minor being odd denotes a development branch and minor being even
> > denotes a stable branch. Thus, 1.0 will be stable and 1.1.x is
> > development.
>
> I'm not that thrilled about two-dot version numbers.  We've been there
> in the FreeBSD project as well, but then found that it makes more
> sense to have single-dot releases by default, with the .patch version
> only supplied if absolutely necessary.  Otherwise, the major==1 will
> probably become a constant. ;-)

Major should change when some part of the API changes or if the
underlying tool deps change. So, for now 1.0 we require:

  binutils >= 2.13
  gcc >= 3.3

For example, if 3.4 requires changes to avr-libc that are not backward
compatible, then we'd need 2.0.

> Also, i think it doesn't make sense to reserve an entire branch for
> development.  Just make the head of CVS for development (and make
> devel snapshots from there), and make one release earlier the stable
> branch.

That was my intent: dev == head, not a separate branch. I just want
the version number to change so we can easily differentiate the
branches when someone says they are using version <foo>. Thus, the
head is always an odd minor version.

>
> I'm not religious about this however, if anybody else is happy with
> the Linux kernel variant, go for it.   You probably won't hear much
> from me for the next couple of weeks afterwards, because i'll leave
> early tomorrow for a (not too long) vacation.
>

That's fine. I don't think we'll be making the release before you get
back.

Ted Roth




reply via email to

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