On 18/08/10 17:14, Ben Fritz wrote:
On Aug 17, 4:56 pm, Matt Wozniski<m...@drexel.edu> wrote:
Most users don't get their vim from source control at all - they get
it from binaries or source provided by their distro.
Developers would want to get the bleeding edge version, and we can
assume the can follow the instructions to sync to a different branch.
I think what would normally happen is to merge the development branch
back into the default branch. But just like the problems you have now,
I suspect that migth not work very well.
Keep in mind that in most opensource projects work that way - I don't
think I've ever checked out code where the starting branch wasn't the
main development branch. If you want an older version, it's easy to
check out an old tag. With CVS or SVN, you'd always get the latest
HEAD, there's no reason for Hg to be any different.
I don't think I can top what Matt says here, I agree whole-heartedly.
When I look at a new project, I personally expect the "latest and
greatest" to be on the main trunk, unless there are spurious
"experimental" branches. I expect that when I want to look at an old
version, I will need to do something special. I expect that most users
will either get pre-compiled binaries when they don't want the
bleeding-edge stuff, or will be willing to do a little extra work to
ensure a stable version.
Also, the Mercurial documentation says that it is "strongly recommended"
to use the default branch for the branch "where active development is
being done". This would mean the bleeding-edge "latest of the greatest"
which receives the most pushes, not some "stable" branch which will be
retired (possibly after some "grace period" during which it receives
only security and stability updates) once the next release achieves
sufficient stability.
Maybe we could have a floating "stable" label that moves from time to
time as new versions get used and tested, to limit the amount of
thinking that goes into getting the latest "stable" build?
In Mercurial that would be a "tag" i.e. a label applying to one
changeset, but which can be moved by tagging a later changeset with the
same tag. The "tip" tag is special in that it always means the changeset
most recently added to the repository; other tags can be moved by an
explicit "hg tag" followed by "hg commit". Each changeset may have zero
or more tags. For instance one may want to tag a certain changeset as
both "VERSION_9_5_RC1" and "VERSION_9_5_RELEASE" then if necessary a
later changeset will be tagged "VERSION_9_5_RC2" and
"VERSION_9_5_RELEASE", thus removing the "release" tag from the RC1
build. Then if the RC2 doesn't exhibit release-breaking buggy behaviour,
it will stay as the 9.5 release build with no additional change to the
repository. (I've seen this kind of thing happen recently while lurking
in the #chatzilla channel at irc.mozilla.org, and a robot announced new
tags being defined for SeaMonkey in the Mozilla "comm-central" hg
repository.)
Best regards,
Tony.
--
Politics is like coaching a football team. you have to be smart enough
to understand the game but not smart enough to lose interest.
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
