Just catching up here on the west coast of the US...
+1 on the modified proposal of aiming for a "less risky" release
called Plone 4.0, with the caveats that:
- The release needs to offer improvements of significant value to
justify the effort in upgrading (Hanno's spreadsheet of proposed
changes and where they might land looks good to me overall)
- We need to nail the upgrade story and documentation of changes.
+1 for Eric Steele as release manager for 4.0 (with Hanno continuing
to oversee Plone trunk)
David
On May 5, 2009, at 7:57 AM, Hanno Schlichting wrote:
Hi.
To summarize the feedback from the European time zone, I think that
the
proposal in general meets the favor of everyone.
The controversial issue is the exact version number to use for the
release. There seems to be broad support for freeing the current Plone
trunk from a version designator and release a 4.0 release with the
envisioned scope of this proposal instead.
If I do not get a strong signal or message otherwise, consider this
proposal changed in this regard.
Hanno
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
David Glick
Web Developer
ONE/Northwest
New tools and strategies for engaging people in protecting the
environment
http://www.onenw.org
davidgl...@onenw.org
work: (206) 286-1235 x32
mobile: (206) 679-3833
Subscribe to ONEList, our email newsletter!
Practical advice for effective online engagement
http://www.onenw.org/full_signup
_______________________________________________
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team
