If we announce some fix date for a version bump, new version fork in the repository or release date for said version, and circumstances would have it we missed that deadline -- would the announce still be worth anything and better than how we did it this time? After all, this situation will occur again, and we could easily have thrown out some date when starting to wrap up things a few weeks or a month ago when Nilsson initiated the release process.
I think the main reason a set date never surfaced was that we know very well release dates are possibly the biggest lies that exist, especially so for as loosely driven projects as Pike. It's also a possibility that a missed release date (either too late or, should some consensus be reached that we are done a week before, early) would have us lose some certain amount of credibility. (Which we supposedly do either way, in not firmly setting down the foot, stomping in a Deadline.)
Personally I'm really glad that we got a fork and release in the first place; those things don't magically happen of their own accord. Surely they can happen differently, but if we do try something else, it would be nice to know in advance how people would react to events that will certainly take place.
/ Johan Sundström (Achtung Liebe!)
Previous text:
2004-05-06 05:35: Subject: Re: Pike 7.6
I understand the desire to get a release "out the door", but in this case, I tend to agree with mast. There were a number of items on my personal todo list, some of which are at present, half complete. Some of them were small, others large (like the tutorial book.) Now, had I known exactly when a branch was going to occur, I could have planned accordingly. I realize that an attempt was made to say, "hey, we're planning on branching sometime soon", but deadlines that don't have dates attached to them don't get my attention, and I'm sure I'm not the only one.
Next time around, I'd like to see a release plan with actual dates. The schedule should include a date for a new feature freeze, at which point all new functionality should be committed, as well as the actual target branch date. These dates should be formally proposed/announced at least a month in advance of the deadlines. Having dates rather than amorphous timeframes allows all of us to coordinate changes and plans. These sorts of "planning" documents should be posted to the website as well, because a) it's a handy reference, b) it helps promote that mystical communication everyone is always griping about, and c) not everyone follows this forum.
As to the comments about having to build release notes, I proposed a solution to that a month ago. At that time, no one voiced an opinion either way. Having a change log that was updated as noteworthy changes get made would make this task simple, if not unnecessary.
Any thoughts?
Bill
/ Brevbäraren