On 8 June 2011 10:20, Volker Grabsch
<address@hidden> wrote:
Hello Tony,
Tony Theodore schrieb:
> We could start with mercurial release branches. Say we found out that
> postgresql had moved their old tarballs to an archive site. We create
> a branch (2.18-release), and fix the urls on that branch. At this
> point we could make the decision about mirroring it ourselves, or
> simply changing to the new location (depends on the type of change I
> guess).
I don't think we should have separate branches for every release.
For example, as soon as 2.19 is released, we don't want anyone to
use 2.18 anymore. It doesn't make sense to maintain download links
to outdated software.
Instead, a single "stable" branch is all we need. Note that this
branch has always been there, but in a quite informal way. That's
why I just created a formal stable branch in the Mercurial repository.
That is, we have two branches by now: "default" and "stable". Although
it might be obvious, here are some guidelines:
1) Any change in the build scripts goes into "default".
2) Any package upgrade goes into "default".
3) Any documentation upgrade that refers to a feature not
present in stable goes into "default".
4) Anything else that doesn't effect the build goes into "stable".
5) Any non-critical improvement to the main Makefile
goes into "stable".
6) Any improvement in the package download URLs or
package version recognition goes into "stable".
7) When in doubt, use "default" rather than "stable".
8) After a successful testing phase, the whole "default" branch
will be merged (moved) into "stable".
Note that the stable branch is not yet documented. I'll add some
notes to doc/index.html as soon as possible.
> Mercurial repos are relocatable, so our next release could simply be a
> tarball of the repo that can update itself with a simple hg pull.
This kind of repository is only useful if the user has Mercurial
installed. In that case, however, the user can simply clone the
stable branch of our repository, no need to download a tarball
at all.
hg clone -b stable ...
> tested a simulated release and update using the steps below [1] and it
> seems to work fine. We could wrap the hg commands in the Makefile and
> do something smart with hgrc so that people don't need to know about
> mercurial - but you get the general idea.
When something goes wrong, the user could just enter "hg pull -u".
Although this is one extra step, it reduces the risk of auto-updates
at an inconvenient times. For example, if the download fails due to
a local change in the *.mk file, an auto-upgrade that possibly
generates a conflict is not desirable. If the user updates consciously,
there won't be such unexpected, unpleasant surprises.
> I don't think mercurial is an unreasonable requirement for a
> developer, maybe future "releases" are simply clones of a branch?
I fully agree with that. However, I think that releases are
still very useful. (see below)
> The automation is only really required if we're thinking about
> releases and tarballs, since we can do updates without these, it
> becomes less of an issue.
Your argument reminds me on what Paul Graham wrote in his
article "The Other Road Ahead": [1]
| Your software changes gradually and continuously. Some changes
| might be bigger than others, but the idea of versions just
| doesn't naturally fit onto Web-based software.
However, he also explains why version numbers are still useful:
| [...] this might sound odd, because we were always announcing
| new versions. This was done entirely for PR purposes. [...]
| When we wanted some publicity, we'd make a list of all the
| features we'd added since the last "release," stick a new
| version number on the software, and issue a press release
| saying that the new version was available immediately.
This is also true for mingw-cross-env: Every new release is
something we can announce, something that draws attention to
our project and attracts new users.
But there is also another reason why version numbers make
sense for us: We can't test continuously. This would require
huge build farms will all kinds of differently configured
virtual Unix systems. Instead, we "crowdsource" this in a
dedicated testing phase. When all developers and users are
testing at once, this is a lot more effective than everyone
just testing here and there. And up to now, this works quite
well.
So we do have those moments where we got some big step forward,
and enumbering those moments (via version numbers) is a natural
thing to do.
Of course, capturing those moments in the "stable" branch is
more elegant than producing release tarballs. But as long as
the world thinks in version numbers and release tarballs, we
should supply those. I guess the currect technical term for
our usage of the stable branch is "rolling releases".
Greets,
Volker
[1] http://www.paulgraham.com/road.html
--
Volker Grabsch
---<<(())>>---