Unico Hommes wrote:
Oliver Zeigermann wrote:
Unico Hommes wrote:
Oliver Zeigermann wrote:
Unico Hommes wrote:
Oliver Zeigermann wrote:
To be on the save side, please check if you agree with the following 2.1 release plan:
- Feature freeze: August 1st
- Creation of release branch for full beta->rc->final->maintenance cycle: August 2nd
- Beta1 release: Ausust 10th
- Max. number of beta releases: 2 (with at most 4 weeks between them)
- Max. number of release candidates: 2 (with at most 2 weeks between them)
- Release Manager: Oliver Zeigermann (will be his final Slide release)
Anything missing? Anything you disagree with?
Is there a minimal term between rc/beta releases?
I have some improvements to ACL in the pipeline but I won't have time to commit them before August 1. These include simple code improvements but also enhancements such as the ability to define custom privileges. I guess these won't be able to make it into 2.1 :-(
Shall we defer the 2.1 release? I guess Slide could need some improvements in the ACL area. I am rather clueless here. As usual I am the problem as I will be on vacation from mid August to mid September. Thus, if we defer the release a beta won't be possible before mid September. A possible solution would be someone else doing the release manager job, but nobody showed up, yet.
I don't want to delay the release for this. ACL does need improvements, they will just have to wait until version 2.2. Releasing early and often is important too.
It's ok to delay the release. Either releasing it now or later will have to work some way if you want it in 2.1...
OK, I am going to do it before august 10. So if it is OK to delay the feature freeze until beta 1 we could still stick the proposed schedule.
Fine with me :)
There is one thing I think MUST be done before the release. I noticed that currently the org.apache.util package is being maintained at two separate places in the CVS! Both in src/util and in webdavclient/clientlib/src/java. Surely this must be consolidated.
Hmmmm, I am not quite sure, as server and client really became seperate projects.
But the class definitions look 90% similar to me. Why would you NOT want that code consolidated. It just needs to be sorted out and the build system needs to be changed a bit. If noone beats me to it I volunteer to do it. Probably won't have time before beta1 though.
I was wondering, this code looks so general isn't it available somewhere else in Jakarta? Maybe in commons?
If not, if have no objections against such a consolidation.
Yes it looks like a lot of stuff that is already in commons httpclient. So code using those classes should be migrated to use commons httpclient code. The remaining stuff should perhaps be moved to a different package since org.apache.util sound a bit too generic?
Would be great if you did that :)
Oliver
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
