[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