[development] Module developers, please do *proper* releases !

[Earl Miles]

Doug Green wrote:
> Earl Miles wrote:
>> I agree that it is inconvenient that sloppy module maintainers do not
>> create releases. ...
> I am a "sloppy module maintainer", but IMHO not a sloppy programmer

I agree with this statement (I had an argument with Morbus about this 
earlier today) but I find the observation is still generally true.

> whose modules should be avoided.  It's a time problem for me.  I wrote
> and maintain, something like 20 modules.  I built most of these modules
> while working on client sites.  It's open source.  I write something
> because it scratches my itch and/or meets a need for a client.  I then
> license it to the world where I know that many of these modules also
> server others needs.

Maintaining 20 modules is flat out difficult.

> I should create a release at the time I finished my client site. 
> However, since my client project is typically over, I've never
> remembered to do this.  If the Drupal Association is going to change the
> way these modules are displayed, then I'll probably start creating
> releases at this point -- when my client engagement is mostly over and
> when the module is running on a client site.

Let's say 'drupal.org' rather than the DA.

> But now, the d.o issue's start coming along... and I maintain these
> modules outside of the client development process.  At what point do I
> create a new release?  After I fix the first bug/feature request?  After
> the second?  After the third?  Multiply this by 20 modules, and for me,
> it comes down to a question of time and help.  I tend to create releases
> when a user reports that I forgot to create a release or when users
> start reporting bugs in previous releases, that I know are already fixed
> in dev.  This is a really difficult problem and question for me. 

Well, look at it from the other side of the coin. When you're building a 
client site, don't you find it easier when whatever module you're using 
has a decent release workflow? There are release notes (theoretically) 
and version numbers. It's easier to report bugs against specific 
versions, and you can get a feel for how far out of date your -dev is. 
And you get some shielding from bad commits.

As for your own processes, this is based upon your personal will. With 
20 modules...I'd imagine you do some work on a module and then don't 
even look at it for months at a time. That's a perfect candidate to have 
a release. If you think you're not going to come back to the module any 
time soon, roll a release. If you've got an important new feature and 
nothing immediate on the horizon, roll a release. If you're not sure 
it's been tested enough, roll a beta release and set yourself a reminder 
to come back to it and roll a real release if you don't get a lot of 
issues against it.

The act of rolling a release, once you've done it a few times, takes 
only about 5 minutes. Be sure to use dww's cvs-release-notes.php which 
will generate release notes from commit logs for you. Then it's a matter 
of...tag, generate release notes, create release node. You are finished.

It's not the time it takes to create the release, it's the focus 
required to come back and do that. I understand how difficult that is, 
but I also believe that you and your users can benefit from his.