We planned for 2007-01-17 because of press release, but the actual build was done with 2007-01-16. The date in the
TWiki is 16 Jan 2007, but the
TWikiHistory and
TWikiReleaseNotes04x01 state 17 Jan 2007.
We need to set the documented date consistently to 17 Jan 2007 in the next patch release.
--
PTh
Why not simply talk about a Build date vs Release Date.
And always put the Build date in the docs and code.
Then the release date used in press releases etc can be offset by days.
This is quite normal to do. In fact most software will be built days or weeks before the official release because it is going through final testing and production in case of boxed versions. You may even have different release dates in different regions.
It is the release NUMBER which is the unique identification of the software.
I find it very wrong to put a different date in the code than the actual build date. It is plain wrong when we talk basic configuration management. The build date and time is important to identify if certain changes came before or after the build. SVN numbers are not chronological!! Really? Yes! You can have a higher SVN number for a change than the release date because the SVN change can have happened in a different branch of the total SVN repository. This is also why I am against the use of SVN numbers only in the change history of extensions. They should have revision numbers and dates as well.
So in future we should separate the build dates and release dates and in fact we should plan 1-2 days between them so we can...
1. Get the entire twiki.org changes complete. We ran almost 48 hours with a 4.0 version of the upgrade guide on twiki.org linked from the release topic.
2. Have 3-4 people testing the build before the official release. We ran 48 hours with a dead link for the zip file because I had typed the file name wrong.
So build date vs release date. That is way.
In our release checklist we should list which of the two that goes where and always refer to the dates as build date or release date instead of just date.
KJL
I close this item, date is fixed for 4.1.0 release.
I think the release date handling should be discussed in Codev.
--
PTh