Breathe in … and Release

I wouldn\’t say I disagree with Jack Unrue\’s statement about releases being necessary, but I think there\’s a way to make both groups happy (and maybe I should just get around to implementing it). If the no-release crowd thinks that we don\’t need to indicate functionality changes in some way, there\’s still an impasse. If that\’s not the case, I may have a solution.

We all know that a URL doesn\’t have to point to a file, so what if http://example.com/releases/my-library_0.3.4.tar.gz created the archive on the fly? It would be built from the \”my-library\” repository, using the tip of the \”0.3.4? branch, using tar -cz (if the user had typed \”.tar.bz2\” on the end, it would have used tar -cj). You can, of course, cache the archive (just check to make sure there are no new commits since the last build).

What are the benefits of this? Well, the developers don\’t need to explicitly build release packages. Also, any bug fixes that get merged into the branch are included whenever the next person requests that archive. It gives the user the same interface that they\’re used to. It works fine with ASDF, etc. (as long as you remember to set the latest tag on your current branch).

Actually, this may work better as a commit hook than being pull-based. This should be pretty trivial to build for any specific source control system. Maybe it\’s my project for this evening.

6 Responses to “Breathe in … and Release”

  1. Steve Says:

    NO! Please no! While it’s a cool hack, and a good substitute for nightly builds, it is not something you want to base a dependent system on.

    Think of it this way: The correct name for the file is not my-library_0.3.4.tar.gz, but in fact my-library_0.3.4+random-snapshot,try-and-guess-which-one.tar.gz

  2. Maciek Pasternacki Says:

    There is problem with creating files on the fly — some uses (e.g. distros) depend on fact that file with the same URL is always the same file (i.e. not only contents, but also md5sum, access times etc.) It’s ok to create files on the fly, but from tags, not from branches; dynamic branch `tar-mirrors’ can e.g. have date in version string or added sub-minor version number, but tagged releases should be static.

  3. Ignas Says:

    If one is using asdf to install libraries automatic packages won’t be pgp signed. Which means that anyone will be able to replace your library with some other code through cliki.

    Another problem when adding the 0.3.4 tag is being sure that that version is stable. Packaging the release is easy, making constantly evolving library stable enough for a tagged release is more difficult especially with many developers. Most of the time you have to maintain some stable branch of your library which adds work.

  4. Lu?s Oliveira Says:

    Brilliant idea! :-)

  5. Anonymous Says:

    I think that approach is confusing. I can download the same URL twice and end up with two different source archives. If I run into problems the archive, how am I going to answer the question: “Which version do you have?”?

    The approach is counter to how almost all open source projects release source archives. You make a release, you name the archive appropriately by including a release version and you upload it to an FTP or HTTP location and leave it there, possibly signing the release cryptographically.

    This is probably handy for OS distributions like Redhat or Debian too, who will possibly automate the fetching of source archives to mirrors while checking md5sums.

  6. Dave Roberts Says:

    You’re solving the wrong problem. Jack’s issue isn’t that tarballs aren’t available. It’s that releases aren’t locked down and tagged. Put another way, how do you know that tarballs aren’t being generated dynamically at all those sites that have them? Answer, you really don’t. What you do know, though, is that anything that is labeled as release x.y.z is a known thing that won’t change from that point on. It becomes a point of reference for all downstream dependencies. So, the hard part that Jack has issues with is that people don’t commit to releases and give them release numbers/names, whether tagging them in a darcs/cvs/svn repo or creating tarballs. The fundamental issue is the lack of committing to a name, leaving everybody only with “Thursday, November 16, 2006, 9:43 AM PST” as a way of identifying which code somebody might be working with. That’s terribly inconvenient and may be error prone depending on how diligent people are about not breaking builds by checking in inconsistent source files into the repo.

Leave a Reply