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.