|
osdir.com mailing list archive |
|
Subject: Re: Five 1.1b: i18n for forms - msg#00069List: web.zope.z3base.fivePhilipp von Weitershausen wrote: yuppie wrote: Philipp von Weitershausen wrote: Tres Seaver wrote: A second issue was to trim out the stuff which was not actually part of the release. This is something which *should* be done for any release, but was overlooked in November (release management is *hard*). The X3.0 branch should already have everything trimmed that isn't part of X3.0. Other than that I don't think we need to trim anything if we point the svn:externals to a release tag of X3.0.y. Please note that the ZopeX3-3.0 branch contains bugtracker, zope.app.workflow, zope.dependencytool, zope.importtool and zwiki. Indeed, and they probably should have been removed. On the other hand, I don't think their existance is of that much importance because they're not in the 'zope' tree and not in the packaged release. ??? zope.app.workflow, zope.dependencytool and zope.importtool *are* in the 'zope' tree and they should not be released with Zope 2.8.1. Sorry, it was late :). You're right of course. Those in zope tree (and the ones you mention seem to be indeed the only ones) shouldn't be there. If y'all think they should be gone, I can delete 'em. srichter re-added bugtracker, zope.app.workflow and zwiki explicitly on the ZopeX3-3.0 branch to make sure they are kept in sync with that branch. So I guess you should ask him before removing those again. I will. However, if you what say is true (and I believe you ;)), it is probably a good idea if we wouldn't remove them on the X3.0 branch. Instead, we can follow the current practice and make a special tag for X3.0.1-2.8, however this time based on the offficial X3.0.1 release tag. In that X3.0.1-2.8 tag we remove the packages and point Zope 2.8 to it instead of the actual release tag, just like we do now. The advantage will still be that future X3.0.y and 2.8.z releases will come from the same main line; on the downside, tagging X3.0 for Zope 2.8 releases will be a bit more complicated. I would document this in http://dev.zope.org/Zope3/MakingARelease though. Philipp Thread at a glance:
Previous Message by Date: click to view message previewRe: Five 1.1b: i18n for formsHi Phillip! Philipp von Weitershausen wrote: I merged/integrated the ZopeX3-3.0.0-Zope-2.8 branch into the main X3.0 branch now; as for the data managers (mail and rdb) I've taken care so that they will work with both ZODB 3.3 and 3.4 (for the mail data manager I actually followed my above idea to have two separate ones). If you want to follow my changes, read r37415 through r37425. I'm open to suggestions if you see something that you don't like. Looks great! Yvo, Lennart and others: the branch is waiting for your bugfix backports now. Just be sure to run the tests on both X3 standalone and a Zope 2.8 sandbox (I removed lib/python/zope from mine and symlinked it to Zope-X3.0/src/zope). I talked to Andreas and let him know about the X3.0.1 release. I will tag it the same day he'll tag Zope 2.8.1beta, which means sometime on Thursday. Please be ready by then; don't forget your entries to CHANGES.txt. Today I'll not have much time, but I can work on this tomorrow. I haven't decided yet whether to do a X3.0.1beta on Thursday or just make it a final. If we do the beta, we wouldn't necessarily have to release it as a tarball; it could just exist in Zope 2.8.1beta for the time being. X3.0.1 final would then be released as a tarball, together with Zope 2.8.1 final. What do you guys think? I guess that's up to you. Don't know if we'll get more feedback with a beta release, so it might not be worth the effort. Cheers, Yuppie Next Message by Date: click to view message previewHeads up: Five 1.0.3Hi there, Lennart has checked in some fixes to Five 1.0, enough to warrant a 1.0.3 release. The timing couldn't be better since Zope 2.8.1beta is approaching. I'll be tagging Five 1.0.3 tomorrow during the evening hours CET. That is so that Yvo has time tomorrow to merge the i18n fixes from the Zope 3 trunk (some of them need to go into Five because we duplicate some form code). I will tag Zope X3.0.1 after that. Philipp Previous Message by Thread: click to view message previewRe: Five 1.1b: i18n for formsPhilipp von Weitershausen wrote: yuppie wrote: Philipp von Weitershausen wrote: Tres Seaver wrote: A second issue was to trim out the stuff which was not actually part of the release. This is something which *should* be done for any release, but was overlooked in November (release management is *hard*). The X3.0 branch should already have everything trimmed that isn't part of X3.0. Other than that I don't think we need to trim anything if we point the svn:externals to a release tag of X3.0.y. Please note that the ZopeX3-3.0 branch contains bugtracker, zope.app.workflow, zope.dependencytool, zope.importtool and zwiki. Indeed, and they probably should have been removed. On the other hand, I don't think their existance is of that much importance because they're not in the 'zope' tree and not in the packaged release. ??? zope.app.workflow, zope.dependencytool and zope.importtool *are* in the 'zope' tree and they should not be released with Zope 2.8.1. If y'all think they should be gone, I can delete 'em. srichter re-added bugtracker, zope.app.workflow and zwiki explicitly on the ZopeX3-3.0 branch to make sure they are kept in sync with that branch. So I guess you should ask him before removing those again. Cheers, Yuppie Next Message by Thread: click to view message previewRe: Five 1.1b: i18n for formsPhilipp von Weitershausen wrote: Tres Seaver wrote: Philipp von Weitershausen wrote: As for the Zope X3-3.0.0-Zope-2.8 branch, I don't know what happened there and what the changes compared to the Zope-X3-3.0.0 tag are. I wasn't there when the branch was created and I actually think it's a bad idea to have done it anyway. It should have been a tag IMO. It couldn't be: ZopeX3-3.0.0 was (trivially) incompatible with ZODB 3.4 (which added actual method signatures to interfaces asserted by code in Zope). I guess you're talking about the changes to IDataManager which affects the MailDataManager: http://mail.zope.org/pipermail/zope3-checkins/2005-April/024613.html http://mail.zope.org/pipermail/zope3-checkins/2005-April/024669.html http://mail.zope.org/pipermail/zope3-checkins/2005-May/024993.html I propose to keep two separate MailDataManager implementations, one for ZODB 3.3 and one for ZODB 3.4. I merged/integrated the ZopeX3-3.0.0-Zope-2.8 branch into the main X3.0 branch now; as for the data managers (mail and rdb) I've taken care so that they will work with both ZODB 3.3 and 3.4 (for the mail data manager I actually followed my above idea to have two separate ones). If you want to follow my changes, read r37415 through r37425. I'm open to suggestions if you see something that you don't like. Yvo, Lennart and others: the branch is waiting for your bugfix backports now. Just be sure to run the tests on both X3 standalone and a Zope 2.8 sandbox (I removed lib/python/zope from mine and symlinked it to Zope-X3.0/src/zope). I talked to Andreas and let him know about the X3.0.1 release. I will tag it the same day he'll tag Zope 2.8.1beta, which means sometime on Thursday. Please be ready by then; don't forget your entries to CHANGES.txt. I haven't decided yet whether to do a X3.0.1beta on Thursday or just make it a final. If we do the beta, we wouldn't necessarily have to release it as a tarball; it could just exist in Zope 2.8.1beta for the time being. X3.0.1 final would then be released as a tarball, together with Zope 2.8.1 final. What do you guys think? Hmm, I wonder why we're having betas for minor releases anyway. Andreas already dropped the practice for the 2.7 branch, I'm surprised he still wants to do it for 2.8. Philipp Loading Comments...
|
|
