I see nothing wrong with any of this, except that it could have been communicated before the release.
(That reminds me that I forgot to write anything about your certificate changes...)
/ Martin Nilsson (räfsfiskal)
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