Re: [Framework-Team] Plone 3.5
On 5 May 2009, at 12:44, Hanno Schlichting wrote: The general idea that seems to have met some consensus is to go for a Plone 3.5 release up next. We'd skip any 3.4 release and go for a 3.5 that is similar in spirit to the Plone 2.5 release. It tries to both refresh some of our technical underpinnings in addition to some more intrusive feature changes we didn't allow ourselves in the 3.x series so far. Why skip 3.4? That Plone 2.5 was a major release was quite nasty, it confused people about what was a major release and what isn't. We've made a commitment to 3.x being stable, I think we should keep to it. Releasing a Plone 3.5 would confuse the matter. However, it would be interesting to open the new features to a wider audience ASAP. I'd be in favour of this if: - It wasn't called Plone 3.x or 4.x (Dunno what though) - We maintained 3.x as officially supported Matt ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Plone 3.5
for the record, i think this is a great idea. this will also take some weight off of the 4release, since some of its low-risk components will have had some real-world usage by then. also, it should make migrations from 3.x to 4.x easier, i could imagine. i'm also more than fine with eric as 3.5 release manager. thanks for volunteering, eric! just my €0.02, tom On 05.05.2009, at 13:44, Hanno Schlichting wrote: Hi. While everyone is waiting for Plone 4 and its rather long timeline, some people have been thinking about how to bridge the gap between the current stable 3.x releases and the future. The general idea that seems to have met some consensus is to go for a Plone 3.5 release up next. We'd skip any 3.4 release and go for a 3.5 that is similar in spirit to the Plone 2.5 release. It tries to both refresh some of our technical underpinnings in addition to some more intrusive feature changes we didn't allow ourselves in the 3.x series so far. In order to frame the scope of such a release I made a listing of some of the potential features for such a release at http://spreadsheets.google.com/pub?key=rFHYANxtkRfGYchi1QuS5dA. The list is both non-exclusive and non-binding in the recommendations. The envisioned timeline for a Plone 3.5 release would be to aim for a final release either by the time of the conference or by the end of this year, giving us six months or a bit more for it. By aiming for an after-summer beta deadline we will have a chance of leveraging some Google Summer of Code contributions for such a release. When it comes to the official personal involved in such a new major release, I'd like to suggest a slight deviation on our process. As many to all of the features changes in question for the 3.5 release have so far been in the scope of the 4.0 release, I'd suggest to appoint the entire 4.0 framework team to be the official team for 3.5 as well. This forces them to get involved with the process in a more defined and clear way now. On the side of the release manager, Wichert has signaled that his workload as a freelancer will not allow him to take over the shepherding of a new major release. We do however have with Eric Steele of PSU fame a well-known interested candidate for the position. This is only a proposal that needs community feedback and encouragement at this point to make it into an official roadmap. The next steps are to have an open discussion about this for the next one to two weeks. If it meets general favor, we will appoint the new/old framework team and let them recommend a release manager to the Foundation board for official nomination. Cheers, Hanno ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Plone-docs] [Framework-Team] Plone 3.5
(sorry if you get this twice) The idea is also to catch up with our platforms (Zope 2, Zope 3, CMF) as we're starting to look a bit out of date on Zope 2.10 + Zope 3.3 + CMF 2.1. What's the significance of 3.5? Why can't this catch up be done in increments? 3.4 then 3.5 then 3.6? My worry here is that catching up will mean a repeat of 2.5. Not to mention if we are changing this much stuff on a platform level that it won't get documented. The framework team would have to be responsible for documenting these changes as the documentation team just does not have the man power. Sure, we made the 3.3 release w/ documentation and that was relatively small stuff. If you go for a bigger release under the 3.x series we're going to end up back where we startedNew technologies and no documentation. This will further the idea that being a Plone developer is only for elite code jockeys. That's not really something we want to reinforce, is it? I gotta tell ya, this idea makes me really really nervous. I thought the whole point of 3.x was to be stable and not repeat past mistakes? I'm all for getting closer to 4.x but we need to do it in bite sized steps, not all at once. J. ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Plone 3.5
I'm leaning towards naming the new intermediate release Plone 4 rather than Plone 3.5, and change what we previously thought of as Plone 4 to Plone 5 or Plone Future (until it becomes close enough in time to give it a version number). Plone 3 has been stable and a safe choice, and jumping to 3.5 with bigger changes can only confuse people. -- ___ Helge Tesdal · Senior Developer, Jarn · www.jarn.com Plone Solutions, Development, Hosting and Support ___ ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Plone 3.5
Hanno Schlichting wrote: Hi. While everyone is waiting for Plone 4 and its rather long timeline, some people have been thinking about how to bridge the gap between the current stable 3.x releases and the future. The general idea that seems to have met some consensus is to go for a Plone 3.5 release up next. We'd skip any 3.4 release and go for a 3.5 that is similar in spirit to the Plone 2.5 release. It tries to both refresh some of our technical underpinnings in addition to some more intrusive feature changes we didn't allow ourselves in the 3.x series so far. -1 on skipping 3.4. It will mostly bring more confusion. People will ask why, and most, manly newbies and outsiders who don't understand the complexity of the Plone stack, won't understand the rationale behind it. Also people will expect a 3.5 release to keep the promise of stability of the 3.x series. In order to frame the scope of such a release I made a listing of some of the potential features for such a release at http://spreadsheets.google.com/pub?key=rFHYANxtkRfGYchi1QuS5dA. The list is both non-exclusive and non-binding in the recommendations. It would be great to have such improvements before Plone 4. But I think most of these features, specially the ones tagged as low risc can, and should, be included in the 3.x series (3.4, 3.5, ...), without breaking backwards compatibility. Although, some may need special attention in regard to bbb. I don't think there is a good solution here, but it will be less painful if we don't mess up with version numbering. Just my 2 cents :) Ricardo -- Ricardo Alves r...@eurotux.com Eurotux http://www.eurotux.com ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Plone 3.5
[Do we really need to discuss this on three lists?] Martin Aspeli wrote: JoAnna Springsteen wrote: The idea is also to catch up with our platforms (Zope 2, Zope 3, CMF) as we're starting to look a bit out of date on Zope 2.10 + Zope 3.3 + CMF 2.1. What's the significance of 3.5? Why can't this catch up be done in increments? 3.4 then 3.5 then 3.6? Because upgrading Zope versions and some of the other changes are too big for the Plone 3.x stability promise. Do we know that for sure already? Do we know how far we could get with some temporary module aliases to take care of stuff that has been moved around? My worry here is that catching up will mean a repeat of 2.5. What does that mean? That we confused people to now end ... As I understand the current discussion the general idea is most welcome. People are concerned of staying in line with our long-term promises and it seems to me that this almost exclusively boils down to a naming issue. Frankly speaking I would have no problem calling the proposed intermediate release Plone 4 and not to assign a version number to current trunk at all. AFAICS the current co-notation of Plone 4 being the all-new, all-shiny next generation of Plone is merely a project internal that we can redefine without much of a problem but doing it the other way around because we consider sneaking in a major release before the next major release that some got used to think of being Plone 4 carries the risk of creating confusion and distrust where we can't control it. Raphael ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Plone-developers] [Framework-Team] Plone 3.5
On 5. mai. 2009, at 22:26, Alec Mitchell wrote: I'd like to stand up for my release a little, since people seem to be implying it was some sort of expectations/compatibility disaster. I don't consider it a disaster. To me it's more about the community learning from mistakes, identifying areas of improvement and getting better by each release. If we were more happy with Plone 2.5 than 3, we would have a real problem. :) -- ___ Helge Tesdal · Senior Developer, Jarn · www.jarn.com Plone Solutions, Development, Hosting and Support ___ ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
