Wednesday, November 15, 2006

"we don't do releases"

I have encountered several CL libraries whose dev teams are either indifferent about doing official releases or have an explicit statement on their project website(s) notifying the world that they don't plan to spend time on such activities. One project in particular observes that formal releases are a lot of work and they can be troublesome, and hey installation is as easy as typing `darcs get blah...'

What these developers fail to recognize (or maybe don't care about) is that this attitude puts the next developer down the foodchain in a difficult position. Here's my perspective -- every dependency of my project is automatically a dependency for my users. When the current source control version doesn't work or whose API/behavior is changing dramatically from day to day, this becomes my problem. I am in a much better position to debug such an issue or look for a substitute, so I don't think it's fair to ask my users to do it. Obviously, I prefer to have some control over the situation, such as being able to say "the version of foobar I have tested for use with my project is 0.x.y patchlevel z". But when a project's release procedure consists of telling people to check out the latest from source control, I have little or no control over which version my users actually get.

So when I see a library that looks useful but doesn't do official releases, I have to decide amongst three choices: a) move on in the hopes of finding an equal or better alternative, b) bundle a snapshot of the library inside my own project, or c) nag the developers to make snapshots available that others can depend on being available (for some useful amount of time). None of those are good choices, frankly.

One last comment...I'm not complaining about brand new projects whose websites are barely a week old. In cases like that, one generally either sees a statement like 'this stuff is brand new and we haven't done any release yet' or it's just easy to tell. Every project has to start somewhere. My beef is with projects that have been around and whose developers really ought to know better -- this is basic configuration management.


Dave Roberts said...

yup, agreed

Anonymous said...

Additionally, it would be great if upstream would label their source archives "foo-x.y.z.tar.gz" instead of "foo-latest.tar.gz".

And if you're going to use the :version slot in defsystem, please try to keep it synchronized with your actual release version.

If your source archive unpacked into a versioned subdirectory, that would be sweet to. Then I could easily diff versions without clobbering them. This suggestion is just a convenience thing though. The first two are more important.

Jack Unrue said...

Good points! I have slipped up occasionally on those details myself.

dons said...

Thanks for raising this issue. It's something we have to remember to avoid in the darcs-centric Haskell world too. Good, distributed, public revision control systems can make devs lazy about releases.

However, since creating a tarball is as easy as typing darcs dist, there's really no excuse.

Jason Dagit said...

If the maintainers feel anything which makes it into the public darcs repo is fair game for users this creation of a tarball can be completely automated.

put the following in _darcs/prefs/defaults:
apply posthook darcs dist
apply run-posthook

Now whenever patches are pushed to the repo a dist tarball will be generated. (Note, you may also want to add a command for zipping if you like to create .zip files.)

Anonymous said...

I would not call 'making a tarball' a release.

A release means that there is some effort to create working software with documentation and instructions in sync with source. It also means that the release has a described features set with a delta to a prior release (new feaures, bug fixes, open issues, ...). It also means that installation instructions have been tested on the various platforms (and the problems found are fixed or described). Well, actually the whole software and build system should be tested and the the test results documented. That would be a RELEASE. A tarball is just a tarball.

Anonymous said...

Similar problem with Debian, where there aren't revs, just the snapshot at a certain moment.

So if a company is to use Debian, they either have to build their own images from a certain download or else have everyone with a slightly different version depending on the exact time they downloaded or did their latest aptget update.

Christophe Rhodes said...

I'd like to take issue with the phrase "ought to know better". It's not actually your upstream's job to make your own life easier, unless they choose to take it on; often, your upstream is providing software to meet their own needs, and releasing it to help others meet their needs if possible.

Since you actually know your own needs better than anyone else does (let's hope so, anyway), you are in a better position to be able to articulate to your upstream what you would like. Whether that's achieved by simply communicating what you'd like to the developers of the project, or by some more technical means (say, they give you commit rights so that you can do "cvs tag") is a matter for individual cases.

I'm not sure why you think that communicating with upstream developers is "not a good choice, frankly"; maybe it's that it's too much like actual work? To be frank in return, I don't want users who don't invest anything in the software; someone who simply sucks code down does me no good at all.

Jack Unrue said...

[NB: I've changed my reply identity from "jack" to my full name].

You're right that it's not upstream's job to make my life easier; they have the right to decide how and where to spend their available time. At the same time, I have the right not to use their code. Do we release code as a navel-gazing exercise, or do we want people to actually use it?

Anyone that has experience developing software should absolutely "know better." It's a question of professionalism. A project has greater value when the kinds of details that the other replies mentioned are addressed on a regular basis -- and experienced developers know that.

As for your final point, Christophe, I can see how others might intepret what I wrote that way. I agree that it's always a good idea to give constructive feedback. What I meant was that having to beg the developers to make proper releases is very likely a waste of *my* time, particularly if they have a statement right on their project page about it!

Christophe Rhodes said...

A project has greater value to you if upstream takes care of various quality assurance issues. What you seem not to be acknowledging is that your own value judgments may not align perfectly with those of whoever wrote the code in the first place – and yet you tar with a broad brush all those who don't have the policies that you find expedient.

I think that there are many reasons why software might get developed in public without a particular need felt by those writing the code to do release engineering: and for evidence, I'll point at all the smart people who you think should "know better". What if they do in fact know better, in that they know why they release code, and it isn't to make your life easy? They might well have users already, all the users they want, and they don't want someone who will be all take and no give to come along.

Of course you have the right not to use code that doesn't meet your needs; if that had been all you said, I wouldn't have taken issue with it. Nor would I have taken issue with the notion that maybe it is better in general if release engineering could be done in an agreed, well-planned, uniform manner; I think in an ideal world that would be a great thing.

But you took it upon yourself to judge that those not playing by your rules should "know better", and that if they don't want you to use their code they're just "navel-gazing" and unprofessional. I don't accept that judgement, and I said as much.

Jack Unrue said...

Christophe, thanks for your thoughtful replies. I'm glad, and also not surprised, that we agree that release engineering (as a topic independent of this discussion) is a good thing.

If a project team is happy with what they are doing and they have happy users, then by definition they don't care if someone outside that group thinks it's unprofessional. Even in the case where it's a developer that consciously knows he or she is making such a choice, that doesn't change the fundamental nature of the choice.

This is not just about my individual point of view. I am very confident in my belief that others not only share this view but have also reached the same conclusions about libraries they have evaluated, now and in the past. I can tell you that in previous jobs, when my colleagues and I went looking for existing projects to use (rather than reinvent the wheel), we definitely considered release engineering in the criteria for deciding which projects were worthy of further investigation.

To try to isolate this issue as just Jack Unrue not being happy is to deny that the problem exists.

Jack Unrue said...

One other point that I didn't adequately address -- I see nothing wrong with expressing my views, even if it looks like I'm passing judgement on others. Especially regarding a topic that I think for some people is the elephant in the room that they don't want to talk about.

Christophe Rhodes said...

It's not just about your point of view if you say that your needs and the needs of some with whom you have worked in the past aren't best served by unreleased projects.

It is just about your point of view when you say that those who don't behave for your convenience are unprofessional, navel-gazing and should know better. By all means express your views — it's your blog, after all — but don't be too surprised when someone calls you on them.

Chris said...

Christophe, the issue is whether communities are better served by proper release management.

"I'd like to take issue with the phrase "ought to know better".

"Knowing better" can mean quite a few things. Do these developers believe that being part of a community (in this case, the CL community) of developers is beneficial to themselves as well?

Christophe, I believe you're a little too close to this being directed at CL developers, and it wouldn't be bad to have a more detached, generalized perspective of open source development in general.

I don't want to sell open source developers short by saying "well, it's just open source, what can you do?".