|
Author
|
Message
|
|
Damien Pobel
|
Friday 25 February 2011 2:25:53 am
Hello the board Nice to see some moves :-) My comments :
- Why a community release every two months ? I think it will be quite time consuming and not really necessary. I would prefer a big release every six months (like now) and perhaps a maintenance release 3 or 4 months after just before the creation of the "innovation branch" ? This way there's always a recent stable version and the work is concentrated on fixes bug in the beginning of the cycle and on new features in end.
- If understand correctly, just after the release of the community version, the big new feature should be merged in the entreprise edition. I guess it's to propose a very well tested version of the feature in the EE and it's to answer to the question "How do we preserve full migration-ability between eZ CP and Enterprise Edition ?" But what happened if the merge is not done that seems to be the case in the slide for the branch "new template engine" ?
Cheers
Damien
Planet eZ Publish.fr : http://www.planet-ezpublish.fr
Certification : http://auth.ez.no/certification/verify/372448
Publications about eZ Publish : http://pwet.fr/tags/keywords/weblog/ez_publish
|
|
Ivo Lukac
|
Sunday 27 February 2011 9:33:20 am
Hi all, Generally, two months cycle seems a bit to much. It is not important to have releases every month or two, it is more important that the contributions are pulled to master quicker. If someone wants a brand new feature he can checkout the master always. So my concern is that the 2 month cycle would generate more housekeeping work than you can handle. In that way slow down the pulls. Anyway, I covered some more of my ideas here: http://goo.gl/gQZGC so I will summarize few questions regarding this proposal: 1. Will CP include more interesting community extensions, not just with "ez" prefix, but also very mature ones developed by experienced community members? Even include it in the installer as a option to switch on? (we need to give the innovation as fast as possible to the users) 2. Will CP include not just tar.gz but also deb, rpm, vmware appliances, etc. ? (we need to have as simple as possible ways to install, test & choose) 3. Will there be a possibility to add more community design extension to have richer demo content (the more richer demo content, the more people will like the product - we need to show the potential)
http://www.linkedin.com/in/ivolukac
http://www.netgen.hr/eng/blog
http://twitter.com/ilukac
|
|
Gaetano Giunta
|
Sunday 27 February 2011 9:58:49 am
@Ivo interesting comments. I think that the number of people willing to participate in setting up those processes will matter as much, if not more than, the policies/goals that we set up. Getting .deb and .rpm up will take quite a lot of time. Having more extensions packaged could also be a good idea, but another option could be to concentrate on a one-click-extension-installer...
Principal Consultant International Business
Member of the Community Project Board
|
|
Tom Usher
|
Monday 28 February 2011 5:50:29 am
I'm not sure how technically viable this is, but if the eZ Core was less coupled with its evolving components and the majority of new developments came in the form of extensions/addons, then the Enterprise and Community releases could be treated as 'distributions', including a stable version of the core/kernel and a set of extensions deemed suitable by the maintainers of each. eZ Core would be the bare minimum required for an eZ installation, with point releases where necessary and a major release every year or two - ideally with no extension API changes between point releases. Extensions would contain all the 'features' of eZ and would evolve and be versioned separately from the Core. Being able to fork an extension and use it as a 'drop-in' replacement for an eZ Systems extension would mean people could expand on individual features as they need. The eZ Systems supported releases; Enterprise and Community would be a distribution of a certain combination of extensions and the core. Enterprise would likely only include a tested, stable and supported version of the core, with eZ Systems sanctioned, tested and supported extensions. Community might include a more cutting-edge, yet stable version of the core, with less strict requirements for the inclusion of extensions. These distributions could be released more frequently, as newer versions of extensions are made available. This would also allow for third-party distributions, or for more advanced eZ Publish users to start with Core and add extensions only as they require. I'm sure this would require a significant overhaul of the eZ Core and extension API, but it's where I'd personally like to see eZ Publish end up.
|
|
Gaetano Giunta
|
Monday 28 February 2011 7:58:30 am
@Tom: is this not what is happening already? Most of the new developments from eZ Systems have been in separate extensions for a while now, from ezflow to ezie. And besides management of rss feeds and the webshop module, there is not a lot that could be stripped out from the current kernel. The API exposed to extensions has always been very stable - even though it was not clearly defined in the first place, with the result that now we are in an "everything has to be stable" situation that causes great pains in maintenance. What is missing is imho more related to community work: a lot of extensions are never updated by their authors (abandonware); many of them are not very clear-cut in their scope (the "we do some templates but also a workflow because I needed them like this in a particular project" syndrome); many duplicate functionality from others. Last thing: there is a significant maintenance burden in moving big parts of functionality to extensions! While the kernel can be stable and well tested, what do you do when ext. B depends on ext A, and the user wants to upgrade but A has no bugfixes / updates ready (or viceversa)?
Principal Consultant International Business
Member of the Community Project Board
|
|
Robin Muilwijk
|
Wednesday 16 March 2011 1:16:08 pm
Hi, Thanks to those who have given feedback already. Any feedback is welcome, a very comprehensive one like Ivo did (thanks Ivo!), but if it is just a few words it's very welcome also. Even if it's just to confirm our ideas, or not. This is the first request for comments (RFC) from the Board, and our main goal is to let he community have a say in things. Specific to this RFC, we are thinking about participation and also innovation. There will be lot's of areas where participation will be possible, as it was and is right now, but with regards to development we like to open up more. Make it possible for community members and developers to contribute to the Community Edition. @Ivo and @Damien: our idea/proposal to have a 2 month release cycle is to improve this contribution and innovation on the Community Edition. Let's see what others think about this. To the community: this RFC is open until March 24th, so roughly one week left. Please raise your voice! You must have had at least a thought about it shortly... share it with us. Kind regards, Robin
Board member, eZ Publish Community Project Board - Member of the share.ez.no team - Key values: Openness and Innovation.
LinkedIn: http://nl.linkedin.com/in/robinmuilwijk // Twitter: http://twitter.com/i_robin // Skype: robin.muilwijk
|
|
Jean-Luc Chassaing
|
Friday 18 March 2011 3:34:53 pm
Hello community, So, here's how I see things. Trying to make a stable core is a very good thing. Meanwhile exporting things from the kernel to extensions should not become a trap and make ez become a drupalish cms for wich you would have to gather a full lot of extension to have all the necessary features. That was my first point. For the release policy, I think that the community release should not only be the "experimental" part of ezPublish. What I mean is that I think that we should keep in mind that the community release can be used by those who can't afford to have a premium licence. For those, there should be a clear release that could be downloaded. As well for the extensions, each time a release is provided, it should be clearly identified in the repository ; for example, the ezfind 2.3 that came with the 4.4 release of ez Publish is not clearly identified on the git. I think that the two months release cycle could be suitable for the community release but it will be a good thing if it concerns the core and the extensions.
|
|
Guillaume Kulakowski
|
Sunday 17 April 2011 10:55:08 pm
I think is very strange that eZP Enterprise and Community don't have the same version. I think also that have 2 différents release date is not a good choice. The Buzz effect is divide by 2
My blog : http://www.llaumgui.com (not in eZ Publish ;-))
eZC on RHEL : http://blog.famillecollet.com/pages/Config-en
eZC on Fedora : just "yum install php-channel-ezc"
|
|
Ronan Guilloux
|
Monday 18 April 2011 5:45:04 am
Hello community board, For now, upgrades documentation, php scripts & sql commands are enterprise-versioned : 4.4, 4.5, and so on. Will the community versions be released with such scripts & documentation in the future? (any "Upgrading from 4.5 CP1 to 4.5 CP2" doc out there ?) Cf. actual scripts : https://github.com/ezsystems/ezpublish/tree/master/update/common/scripts & upgrade doc : http://doc.ez.no/eZ-Publish/Upgrading/Upgrading-to-4.5/Upgrading-from-4.4-to-4.5 Thanks in advance!
--
Ronan Guilloux
|
|
Nicolas Pastorino
|
Monday 18 April 2011 6:19:52 am
"
I think is very strange that eZP Enterprise and Community don't have the same version.
"
Hi Guillaume, I am not sure to understand this. Are you referring to the naming here ?
"
I think also that have 2 différents release date is not a good choice. The Buzz effect is divide by 2
"
Well, given that builds of the Community Project will be made every month, while Enterprise Edition will be released every 6 months, we have two distinct buzz tracks here. But i can see your concern for this very first build : we have been used to having one single version available, making everybody expect a community version at the same time as Enterprise Edition 4.5, with the same content. We have now Community Project 4.2011, the kernel of which is quite similar to 4.5's (two weeks of pull request and commits in addition), two weeks delayed, and opening for a new one every month from now. This is the big change. Do you think that once the build pace of Community Project is properly set and effective, the buzz still will suffer from this ? Cheers,
--
Nicolas Pastorino
Director Community - eZ
Member of the Community Project Board
eZ Publish Community on twitter: http://twitter.com/ezcommunity
t : http://twitter.com/jeanvoye
G+ : http://plus.tl/jeanvoye
|
|
Nicolas Pastorino
|
Monday 18 April 2011 9:03:02 am
Hi Ronan, Thanks for bringing this up. For this first build of the Community Project, 4.2011, you can safely use the 4.4 to 4.5 migration path and tools. They should seamlessly work given the few fundamental differences between 4.5 and 4.2011. For the forthcoming version of eZ Publish Community Project, the Community Project Board is likely to provide upgrade docs & tools between for example 4.2011 and 5.2011.
I hope this helps you,
Cheers,
--
Nicolas Pastorino
Director Community - eZ
Member of the Community Project Board
eZ Publish Community on twitter: http://twitter.com/ezcommunity
t : http://twitter.com/jeanvoye
G+ : http://plus.tl/jeanvoye
|
|
Ronan Guilloux
|
Tuesday 19 April 2011 7:20:59 am
"
"
For the forthcoming version of eZ Publish Community Project, the Community Project Board is likely to provide upgrade docs & tools between for example 4.2011 and 5.2011.
"
"
That's very good news. This sounds sensible, since the Board already arbitrates on pull requests. That should make the community versions even more reliable for production use, which is essential for small/medium web agencies business, & therefore for the all eZ Ecosystem.
--
Ronan Guilloux
|