On Thursday 29 October 2009, Zach Welch wrote:
> On Thu, 2009-10-29 at 03:05 -0700, David Brownell wrote:
> > On Wednesday 28 October 2009, Zach Welch wrote:
> > > I just tagged 0.3.0-rc0 and will post the packages shortly.
> >
> > Great! Thanks. I don't think anyone's going to
> > object to this milestone being "rc0" not "rc1",
> > although it's a somewhat unusual naming convention.
> >
> > Could you elaborate on what you're using? And how
> > the git tags relate to the release labels?
> >
> > Example, currently I see:
> >
> > - 0.3.0-rc0 ... label on tarballs
>
> which was my intention.
Right ...
> > Or from the git tree:
^^^^^^^^^^^^^^^^^
> >
> > - 0.3.0-rc1-dev ... what "info openoccd.info" reports
>
> Really? I just looked inside the packages I uploaded, and that is not
> what they appear to report.
This is from the git tree. Identifying as RC1 there, but
that's not the tag:
> > - v0.3.0-rc0-1-gb628207 ... what "git describe" says
>
> Because the tag is v0.3.0, which is what I thought was our convention
> (after v0.2.0). The 1 is from the version bump that followed the tag.
> I suggest adding the 'v' in the openocd.c and openocd.texi files. ;)
Adding the "v" would be fine, but that's not the issue
which I was highlighting.
The issue is that the tree is identifying itself as RC1,
which DOES NOT EXIST, while the tag correctly reports the
situation as being deltas against RC0.
> > - 0.3.0-rc1-dev-00001-gb628207-dirty ... from "openocd -v"
>
> I was confused by this too. Then, I realized that you must be building
> from Git. Is your working copy clean? If you build from the tarball,
> what does it say? ;) That's what counts, after all....
As I said above -- from git. And the issue is that it's
identifying as RC1, which doesn't exist. The "-dirty"
doesn't matter here; it just means I've got patches
layered on top. (It's a working tree after all!)
> > so it's not very consistent. Tree says rc1 but that's
> > not what the tag says...
>
> I ran the following commands from the top of the current tree:
>
> git checkout master
> tools/release/version.sh bump rc # added -rc0 (could add by hand)
> tools/release.sh --next=rc release # tag and start v0.3.0-rc1-dev
It's that "start v0.3.0-rc1-dev" which is IMO the problem.
In a couple ways:
- We have no RC1, so we shouldn't pitch *anything* as
being related to RC1 until we have one.
- In fact, we don't even know if there *will* be an RC1.
So the followon to "rc0" should not be "rc1"; it could
be "rc0-dev" though. (Or v0.4.0 ... we can't know
until we establish whether more bugfixes are due.)
- The "git describe" info doesn't match "openocd -v".
Another way to look at it: if you take a patch and apply it
to (a) a release, (b) a snapshot, and (c) git HEAD right after
the release, the versions *should* all pretty much agree.
But now, they will not agree ... since HEAD (and snapshots
derived from it) all claim to be some mythical RC1.
And when there's a real RC1 release, it will have updates
that don't appear in any other version tagged "RC1". That
adds confusion... developers can't even ask "Are you using
RC1? That bug was fixed in RC1."
> # gives you on v0.3.0-rc1-dev branch to review, and pkgs in archives/
> git checkout master
> git merge v0.3.0-rc1-dev
> git push sf master
>
> If we want to release -rc1, then it's just:
>
> tools/release.sh --next=rc release # tag and start v0.3.0-rc2-dev
>
> If we think we're ready, we could instead release the final v0.3.0 with:
>
> tools/release.sh --final --next=minor release # start v0.4.0-dev
The version labeling should change, IMO.
> If we want to start v0.4.0-rc0-dev instead, then add --start-rc to that.
> Both variations are worth trying, as they take slightly different paths.
> For example, the script archives NEWS with major/minor releases.
>
> At the moment, the script seems to have performed admirably. I just ran
> a check to confirm this (simulating -rc1), and you should be able to do
> that for yourself now.
I'll do that at some point, but the issue I'm referring to is
not about whether the tools _work_ but instead about the version
labeling.
I don't think anything should be labeled RC1 (etc) until that
version has been released. We should be able to say that such
and such a bug was "fixed in RC1" (etc) and not have any
confusion at all.
But as it stands ... RC1 isn't really a milestone, it's two
different milestones. Confusion.
- Dave
_______________________________________________
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
