> 1) It is still undecided whether we want to include documentation with the > binary releases. Currently they only contain the jar and their > dependencies.
AFAIK, there is no requirement for this. I do think it's important for folks to be able to be able to access offline docs for a specific version. But the binary jars does not seem to be the right place for this. I'd say that there docs should be in the source or a separate download and the binary distro readme should point to where they can be downloaded. > 2) It is also undecided whether we want to provide source packages for the > single modules. The requirements in www.apache.org/dev/release.html says: ... must contain a source package, which must be sufficient for a user to build and test the release.. Unless we plan to change our release/versioning process to allow for different versions of sub modules, I think the single all in one source is fine. > 3) We need to switch the site publishing mechanism to svnpubsub until the > end of year [1]. So some change in the site publishing mechanism is > needed. We need to consider the following: > - We need a location for the site in svn (currently the "default location" > db/torque/site is occupied by the torque 3 site project, see also (5)) > - We probably want to retain the documentation for older releases > - It should be no hassle to create a new site version directory (as we now > have for the old docs of 3.1, 3.2, and the new 4.0 but not the current > 3.3 docs) The strategy Thomas F proposes seems OK. E.g. site-svnpubsub with subdirs for each release. Maybe scm-site or site-scm would be a shorter name? > 4) How much time do we allow for testing before the first attempt to release > 4.0 ? 4.0 is a major change. I think folks will be a bit slow to start kicking the tires due to the learning curve. 2 months might be enough, but I don't think we'd really get a lot of extra testers in that time frame. On the other hand, if stuff pops up after 4.0 is released, it seems like all the good work done to automate the release process would make it easier to do a 4.1 with fixes. I think as long as we know there wouldn't be too many months between missing features reports (e.g. I used to be able to do..) and a release that corrects them, a short 2 month test time is OK. BTW - Did any notices of the beta release go out? E.g. in the site news and to torque-users? If folks don't know it's there, they probably won't test with their local code. > 5) Do we want to reorganize svn by putting the torque 3 resources into a > separate place ? +1... but we should make sure it's well noted in the site. This means that folks with local projects that pull from svn will need to update their local settings. When such stuff breaks, it should be easy to find a notice that the structure has changed. Maybe there should be some "pre-notices" too. E.g, a note on the site, to this list, and to torque-user that the svn structure will change on a specific date (or date range). > 6) I'd like to improve the online docs further by dropping the strict > separation between modules in the docs. +1 - I think this would allow for some needed overview and "rabbit trail" type organization. E.g., what to read to understand using torque vs what to read for modifying/developing topics. I think we sort of have this now, but you have to understand which sub-project you need... which you don't until you start learning things. Lol. DukeCE Privacy Statement: Please be advised that this e-mail and any files transmitted with it are confidential communication or may otherwise be privileged or confidential and are intended solely for the individual or entity to whom they are addressed. If you are not the intended recipient you may not rely on the contents of this email or any attachments, and we ask that you please not read, copy or retransmit this communication, but reply to the sender and destroy the email, its contents, and all copies thereof immediately. Any unauthorized dissemination, distribution or copying of this communication is strictly prohibited. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
