Re: [zeta-dev] Proposal: Release process
Hi Walter, On 11/18/2010 09:51 AM, Walter Rafelsberger wrote: On 11/17/2010 03:58 PM, Jerome Renard wrote: However, for a custom app, it does not make sense to bundle all Zeta Components if you only want to use e.g. Graph or Mail (which are 2 of the most used components). For inspiration you could take a look at Mootools' approach with Core More and their builder: http://mootools.net/core/ http://mootools.net/more/ I really doubt there is enough value in providing customized package downloads for Zeta compared to the hassle. JavaScript libraries offer this way of distribution mainly because their sources need to be transferred to the client quite often (resulting in the need to keep the dist as small as possible) and because there is no unified installer. Regards, Toby -- Tobias Schlitthttp://schlitt.infoGPG Key: 0xC462BC14 Want to hire me? Need quality assurance?http://qafoo.com eZ Components are Zeta Components now! http://bit.ly/9S7zbn
Re: [zeta-dev] Proposal: Release process
2010/11/29 Manuel Pichler m...@manuel-pichler.de: Hi Toby, Am Montag, den 29.11.2010, 11:21 +0100 schrieb Tobias Schlitt: [...] On 11/17/2010 03:58 PM, Jerome Renard wrote: However, for a custom app, it does not make sense to bundle all Zeta Components if you only want to use e.g. Graph or Mail (which are 2 of the most used components). [...] I really doubt there is enough value in providing customized package downloads for Zeta compared to the hassle. here I totally disagree with you. IMHO is it bad practice to force someone to download the complete package, even when only a few components are needed. I would even go so far as to say that it is a must have for each serious framework to allow cherry-picking of the components you would like to use. Same here! Especially in the case of the Zeta components where most of the components are highly decoupled and individually usable! I wouldn't say the same thing in the case of a highly coupled framework like Symfony or Zend Framework! Patrick
Re: [zeta-dev] Proposal: Release process
On Mon, 29 Nov 2010, Manuel Pichler wrote: Am Montag, den 29.11.2010, 11:21 +0100 schrieb Tobias Schlitt: [...] On 11/17/2010 03:58 PM, Jerome Renard wrote: However, for a custom app, it does not make sense to bundle all Zeta Components if you only want to use e.g. Graph or Mail (which are 2 of the most used components). [...] I really doubt there is enough value in providing customized package downloads for Zeta compared to the hassle. here I totally disagree with you. IMHO is it bad practice to force someone to download the complete package, even when only a few components are needed. I would even go so far as to say that it is a must have for each serious framework to allow cherry-picking of the components you would like to use. And that is exactly why we've distributed (and recommended) installations through PEAR! Derick -- http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation: http://xdebug.org/donate.php twitter: @derickr and @xdebug
Re: [zeta-dev] Proposal: Release process
On Thu, 4 Nov 2010, Tobias Schlitt wrote: I have studied the guidelines for releases in the ASF and tried to make up a release process document for us. Please find it attached for discussion. You can also find it in our SVN under docs/release_process.txt My comments: Component releases == A component is typically maintained by a single person or a small group of people (for simplicity, the term *maintainers* is used in following). The maintainers of a component are in charge of proposing when a release should be done. If the maintainers of a component decide that a release should happen, they must choose a release manager. This choice can happen informally among the maintainers of a component. The release manager must tag the release in SVN, prepare a release package from this and upload it to his user space on `people.apache.org`__. He must then call for votes on the developer mailinglist, requesting the package to be tested by other developers. The vote must last **at least 7 days**. Every testing developer is requested to run at least the test suite of the component on his local system. If errors or failures occur, he is requested to vote **-1** on the release. __ http://people.apache.org/ .. note:: Incubating phase After a successful vote on the developer mailinglist, the release manager must open another vote on the Incubator PMC mailinglist for the release. This vote must contain: - A reference to the RC package - A reference to the successful developer vote - A reference to the SVN tag for the release When the vote is accepted, the release manager is in charge of uploading the release to the Apache dist server and to announce the release. Component releases must follow the following scheme, while each release requires the process specified above: - An *alpha* release is to be held whenever a new feature has been implemented for a component. If there are no critical issues reported within 1 week after officially releasing the package, the component can proceed with a *beta* release. Otherwise, the occurred issues must be fixed before a new *alpha* release can be rolled. - A *beta* release is required after *alpha* stage has been completed successfully or if the release only contains bug fixes, but no new features. If critical issues occur 1 week after the release has been rolled, these must be fixed and a subsequent *beta* release must be rolled. I would also stick to what we already had here: http://incubator.apache.org/zetacomponents/community/dev_process.html#version-states - After a successful beta stage, a stable release of the component may be rolled. You miss here: When a release is made, the documentation should be regenerated for latest (which is a list of all the latest made releases from a component). Most of that stuff is documented here: http://svn.apache.org/repos/asf/incubator/zetacomponents/docs/releasing.txt .. note:: Determine how PEAR channel publishing can work within ASF. Proposed is to just maintain a static PEAR channel on the main distribution site. Full package release A full package release does not occur as needed, but fixed dates twice a year. .. note:: Determine release times. I would go with Before Christmas and Before the Summer holidays. The release manager for this release is elected on the developer list through a vote, right after the last release has been rolled. The full package release does not require *alpha* and *beta* stages, since it only contains the most recent stable releases of all components. That's a change from what we had. I would actually go with a beta period as well, where we recheck syntax and docs, and write tutorials if that's not done. In order to roll a release, the release manager must start casting the votes for it in the same manor as described for `Component releases`_ 2 weeks before the release should be published. -- http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation: http://xdebug.org/donate.php twitter: @derickr and @xdebug
Re: [zeta-dev] Proposal: Release process
On Thu, 11 Nov 2010, Tobias Schlitt wrote: On 11/07/2010 11:55 AM, Thomas Ernest wrote: Here comes questions : A/ What is your opinion about the proposal automate full package release ? B/ What are advantages of separating full package release process from component release process ? (It should probably be my first question before writing all this stuff :-)) For A: I would love to see such a process, as said above. For B: An advantage of the previous process was, that component maintainers always tried to have features ready by a defined date, so that they can become part of the full package release. However, I think a more agile way, which allows us to release more fast and often would be nice. It's two othre things that's good to not have too many full package releases: - developers know when things need to get done - users don't get flooded with new releases, and know when there is a full release BTW, in the past, we would also trigger a new bugfix release of a full package once in a while. I would propose that we will restrict that to security issues in the future only. cheers, Derick -- http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation: http://xdebug.org/donate.php twitter: @derickr and @xdebug
Re: [zeta-dev] Proposal: Release process
On Thu, 18 Nov 2010, Tobias Schlitt wrote: Don't get me wrong, I insist of keeping our PEAR channel as the primary distribution way. Absolutely. Derick -- http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation: http://xdebug.org/donate.php twitter: @derickr and @xdebug
Re: [zeta-dev] Proposal: Release process
On Tue, 16 Nov 2010, Tobias Schlitt wrote: as far as I can see there are two major points in this discussion: 1. Providing updates for single components in short time frames could bring people to an update hell, when they need to download and upgrade some components every week. They don't have to. Only for security releases, or when they want to use new features. I think it's a great thing that we can release individual components on such a fast turn around. It means that new features are out (close to) instantly. 2. The clear target of Zeta to provide components as loosely coupled as possible would be lead ad absurdum by only providing full package upgrades. snip However, I see the argument for not having automatic releases of the full package whenever a component is upgraded. This would lead the argument for the full package ad absurdum. Yes. The full package should be twice a year. cheers, Derick -- http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation: http://xdebug.org/donate.php twitter: @derickr and @xdebug
Re: [zeta-dev] Proposal: Release process
Hi all On Thu, Nov 18, 2010 at 10:45 AM, Gaetano Giunta giunta.gaet...@gmail.comwrote: otoh: would we have such info available for existing components or would it be so hard to extract it in a precise and useful way that it would not be done anyway (I mean apart from the obvious compatibility that we get from the complete bundles)? Actually, there is something: http://pear.php.net/package/PEAR_PackageFileManager2 (thanks radagast from #pear for the heads up!) This opens two possibilities: * documenting it's usage with ZC instead or in addition to proposing a full package release * using it to make a full or custom (ie. jquery ui) package archive Regards James -- http://chocolatpistache.com/wiki/public/Contact Customer is king - Le client est roi - El cliente es rey.
Re: [zeta-dev] Proposal: Release process
On 18. nov. 2010, at 07.44, Tobias Schlitt wrote: Hi guys, On 11/17/2010 03:58 PM, Jerome Renard wrote: On Tue, Nov 16, 2010 at 5:43 PM, Gaetano Giunta giunta.gaet...@gmail.com wrote: [...] But think about this: why is eZ Publish bundling the whole of the ZetaC when it only uses a couple of components? Simply because that was the easiest (and quickest) solution when I wrote the build system ;) I agree with you only required components should be included though but this discussion must go to another list ;) without talking too much of eZ Publish here, I think it makes sense in that case. eZ Publish is a framework for which people want to write extensions easily. So delivering the whole Zeta stack provides them with more comfort actually. Precisely, having all components available in such a project, is a big help, as it developers know that they every component at their disposal, for making extensions. Rolling out new features can also make use of components, which is going to be present. And as Jérôme says, it makes the process simpler. However, for a custom app, it does not make sense to bundle all Zeta Components if you only want to use e.g. Graph or Mail (which are 2 of the most used components). Yes. -- Regards, Ole Marius
Re: [zeta-dev] Proposal: Release process
Hi all, I'm not qualified to participate actively to the current discussions, although i'm reading it all. However, i'd like to share how it works with python/pinax projects because it might inspire you. On Thu, Nov 18, 2010 at 9:46 AM, Tobias Schlitt tob...@schlitt.info wrote: Hi Max, On 11/18/2010 09:21 AM, Maxime Thomas wrote: Actually only the packaging of zeta matters as we want to provide everything or a part of it. The jQuery UI package download system seems to be a good start, I guess. Another question comes if we do like this : will it be possible to make heterogeneous packages with this system. I mean can I ask Graph 1.0 with Config 3.2 ? or do I have a minimum rules to follow ? Pinax projects use a requierements.txt file, for example:: --extra-index-url=http://dist.pinaxproject.com/dev/ Django==1.2.1 Pinax==0.9a1 django-debug-toolbar==0.8.3 django-staticfiles==0.2.0 -e git+ssh://g...@github.com:jpic/sorl-thumbnail.git#egg=sorl-thumbnail That file is tracked by the VCS in each project. To deploy a new environment for my project, all i have to do is:: # pip is like pear, for python pip install -r requirements.txt That allows: - each project to have different component dependencies - with specific versions - deployment is piece of cake I don't think it's possible with official pear, anyway: if we decide that it's the way to go then we'll find a way. Regards James -- http://chocolatpistache.com/wiki/public/Contact Customer is king - Le client est roi - El cliente es rey.
Re: [zeta-dev] Proposal: Release process
Another point that has maybe already been discussed but how do we manage components in the SVN, do we have separate tags and branches for the set of components and each component ? My point is to chose the easiest way to deliver things : if each package must be done manually, it increases the probability of mistakes. The best option is maybe to start with a simple package and then see what happend (some feedback of people). We can keep : - the access to SVN - the pear channel with identified version (like ezc) Max 2010/11/18 Gaetano Giunta giunta.gaet...@gmail.com James Pic wrote: Hi all, I'm not qualified to participate actively to the current discussions, although i'm reading it all. However, i'd like to share how it works with python/pinax projects because it might inspire you. On Thu, Nov 18, 2010 at 9:46 AM, Tobias Schlitttob...@schlitt.info wrote: Hi Max, On 11/18/2010 09:21 AM, Maxime Thomas wrote: Actually only the packaging of zeta matters as we want to provide everything or a part of it. The jQuery UI package download system seems to be a good start, I guess. Another question comes if we do like this : will it be possible to make heterogeneous packages with this system. I mean can I ask Graph 1.0 with Config 3.2 ? or do I have a minimum rules to follow ? Pinax projects use a requierements.txt file, for example:: --extra-index-url=http://dist.pinaxproject.com/dev/ Django==1.2.1 Pinax==0.9a1 django-debug-toolbar==0.8.3 django-staticfiles==0.2.0 -e git+ssh://g...@github.com:jpic/sorl-thumbnail.git#egg=sorl-thumbnail That file is tracked by the VCS in each project. To deploy a new environment for my project, all i have to do is:: # pip is like pear, for python pip install -r requirements.txt That allows: - each project to have different component dependencies - with specific versions - deployment is piece of cake I don't think it's possible with official pear, anyway: if we decide that it's the way to go then we'll find a way. shame on pear! otoh: would we have such info available for existing components or would it be so hard to extract it in a precise and useful way that it would not be done anyway (I mean apart from the obvious compatibility that we get from the complete bundles)? Regards James
Re: [zeta-dev] Proposal: Release process
Hi James, On 11/18/2010 10:04 AM, James Pic wrote: I'm not qualified to participate actively to the current discussions, although i'm reading it all. hoo? Why not? However, i'd like to share how it works with python/pinax projects because it might inspire you. Any kind of input is highly welcome! On Thu, Nov 18, 2010 at 9:46 AM, Tobias Schlitt tob...@schlitt.info wrote: On 11/18/2010 09:21 AM, Maxime Thomas wrote: Actually only the packaging of zeta matters as we want to provide everything or a part of it. The jQuery UI package download system seems to be a good start, I guess. Another question comes if we do like this : will it be possible to make heterogeneous packages with this system. I mean can I ask Graph 1.0 with Config 3.2 ? or do I have a minimum rules to follow ? Pinax projects use a requierements.txt file, for example:: --extra-index-url=http://dist.pinaxproject.com/dev/ Django==1.2.1 Pinax==0.9a1 django-debug-toolbar==0.8.3 django-staticfiles==0.2.0 -e git+ssh://g...@github.com:jpic/sorl-thumbnail.git#egg=sorl-thumbnail That file is tracked by the VCS in each project. To deploy a new environment for my project, all i have to do is:: # pip is like pear, for python pip install -r requirements.txt That allows: - each project to have different component dependencies - with specific versions - deployment is piece of cake I don't think it's possible with official pear, anyway: if we decide that it's the way to go then we'll find a way. With PEAR such dependencies are handeled fine and we already reflect them in the $component/DEPS file. However, for building automated packages on the fly for downloading, I think there will be some more effort to take. Don't get me wrong, I insist of keeping our PEAR channel as the primary distribution way. We are only talking about the full package here. Regards, Toby -- Tobias Schlitthttp://schlitt.infoGPG Key: 0xC462BC14 Want to hire me? Need quality assurance?http://qafoo.com eZ Components are Zeta Components now! http://bit.ly/9S7zbn
Re: [zeta-dev] Proposal: Release process
Hi Tobias; On Thu, Nov 4, 2010 at 5:28 PM, Tobias Schlitt tob...@schlitt.info wrote: Hi, I have studied the guidelines for releases in the ASF and tried to make up a release process document for us. Please find it attached for discussion. You can also find it in our SVN under docs/release_process.txt The document summarizes the requirements for releases roughly and then tries to relealize these in a release process specific to Zeta. There are some open issues marked with notes in this document, which need to be decided on. I just read the document and I have a few (nitpicking) questions. In ASF, an **RC is any kind of package that is meant to be published later**, but is at first only provided to developers for testing. How will version numbers will be managed ? I have the feeling the version numbering system will become completely different from the previous versions (eZ Components days). Am I correct ? The first type refers to a release of a single component, independently from any other. Since (almost) all ZC have a dependecy with the Base component, what will be the process in case of (major) update of ezcBase ? Will all the other components released once again ? This choice can happen informally among the maintainers of a component. What does informally means here ? If that means deciding to release over jabber or IRC while chatting with a maintainer after lunch I do not agree. It is not really a of matter of trust but more a matter of transparency. If a (group of) maintainer(s) decide to release a new version of a specific component, fair enough but I think this decision must be sent to the dev-(users ?) mailing list to at least inform that an update will happen. A full package release does not occur as needed, but fixed dates twice a year. I believe you meant every 6 months. Just to avoid any miscomprehension .. note:: Determine release times. How about March and September ? I do not know what you guys think but release in January and June (or July) does not sound that good to me. I also fixed a few minor issues (spelling, typos etc) in the document, patch attached. :) -- Jérôme Renard http://39web.fr | http://jrenard.info | http://twitter.com/jeromerenard release_process.diff.gz Description: GNU Zip compressed data
Re: [zeta-dev] Proposal: Release process
Hi Gaetano, On Tue, Nov 16, 2010 at 5:43 PM, Gaetano Giunta giunta.gaet...@gmail.com wrote: [...] But think about this: why is eZ Publish bundling the whole of the ZetaC when it only uses a couple of components? Simply because that was the easiest (and quickest) solution when I wrote the build system ;) I agree with you only required components should be included though but this discussion must go to another list ;) -- Jérôme Renard http://39web.fr | http://jrenard.info | http://twitter.com/jeromerenard
Re: [zeta-dev] Proposal: Release process
Hi Maxime, On Tue, Nov 16, 2010 at 5:47 PM, Maxime Thomas maxime.t...@gmail.com wrote: [...] And honestly, I cannot see the problem of downloading all even if you don't use some parts. Who can do the more can do the less. Yes, but less is more :D Ok --- [] -- Jérôme Renard http://39web.fr | http://jrenard.info | http://twitter.com/jeromerenard
Re: [zeta-dev] Proposal: Release process
Hi guys, On 11/17/2010 03:58 PM, Jerome Renard wrote: On Tue, Nov 16, 2010 at 5:43 PM, Gaetano Giunta giunta.gaet...@gmail.com wrote: [...] But think about this: why is eZ Publish bundling the whole of the ZetaC when it only uses a couple of components? Simply because that was the easiest (and quickest) solution when I wrote the build system ;) I agree with you only required components should be included though but this discussion must go to another list ;) without talking too much of eZ Publish here, I think it makes sense in that case. eZ Publish is a framework for which people want to write extensions easily. So delivering the whole Zeta stack provides them with more comfort actually. However, for a custom app, it does not make sense to bundle all Zeta Components if you only want to use e.g. Graph or Mail (which are 2 of the most used components). Regards, Toby -- Tobias Schlitthttp://schlitt.infoGPG Key: 0xC462BC14 Want to hire me? Need quality assurance?http://qafoo.com eZ Components are Zeta Components now! http://bit.ly/9S7zbn
Re: [zeta-dev] Proposal: Release process
Maxime Thomas wrote: Sound strange, if we look at what is done elsewhere : - JQuery UI : shared version number - Zend : shared version number - Former eZComponents : both version number also YUI The shared version number implies a kind of packaged application. Else it can be difficult to install and maintain (same as Gaetano). Max 2010/11/16 Patrick ALLAERTpatrickalla...@php.net 2010/11/16 Gaetano Giuntagiunta.gaet...@gmail.com: Tobias Schlitt wrote: Hi Thomas, On 11/07/2010 11:55 AM, Thomas Ernest wrote: Le 04/11/2010 17:28, Tobias Schlitt a écrit : docs/release_process.txt It is a very interesting and useful synthesis. Thank you. The document summarizes the requirements for releases roughly and then tries to relealize these in a release process specific to Zeta. There are some open issues marked with notes in this document, which need to be decided on. I read the document and I focused on the two next issues (or notes) : .. note:: Incubating phase (around line 118) I don't understand what is the matter with this one. Could you tell me more please ? We are currently incubating, which means we are under deeper control of the ASF. For a release that means we need to perform 2 steps before uploading it to the servers: 1. Vote here on the list 2. Have a second vote on the Incubator PMC list Step 1 will also be mandatory once we have been promoted to be a top level project. Step 2 is only mandatory before that. I hope that made it clearer? .. note:: Determine release times. (around line 155) It seems that a full package release is a packaging of all last *stable* component releases. Hence, a full package release could be rolled automatically after every component release. We did not realize such a procedure until now for two reasons: 1. Releasing was not that easy in the eZ Components project 2. Updating the full package install is cumbersome work for users I'd pretty much love to get rid of 1 for Zeta Components, so that should not be an issue in the future. However, the full package cannot be installed automatically by users. They need to manually unpack stuff. This kind of release is pretty much useful for people who just want to take a first look and play around with the code. However, I personally would love to have such automatic package builds, as I would love nightly builds, too. It's just quite some work to realize this and we need a volunteer to take care for it. And I'm not sure if everyone agrees with my views here. So, I see full package release as a sub part of component release process, which involves that : - There is no need for release time. - There is no need for votes. That would indeed save some bureaucratic hassle, yes. :) This possibility relies on the assumption that a full package release hasn't more value-added (or worth) than sum of stable component releases. It means that there is no additional deployment mechanism in full package releases for instance. No, so far the full package releases only contained stable component versions, which were also distributed through the PEAR channel earlier. Here comes questions : A/ What is your opinion about the proposal automate full package release ? B/ What are advantages of separating full package release process from component release process ? (It should probably be my first question before writing all this stuff :-)) For A: I would love to see such a process, as said above. For B: An advantage of the previous process was, that component maintainers always tried to have features ready by a defined date, so that they can become part of the full package release. However, I think a more agile way, which allows us to release more fast and often would be nice. As an end user, sysadmin and app developer, the idea of having per-component release makes my head hurt. While I agree that a more agile build infrastructure is a bonus, as user of the library I do not need at all separate components versions released independently. How could I possibly test the new zeta-c versions, pick the ones to integrate in my projects, decide on timing of upgrades, when a new component might be released every other week? There's a reason the whole world is moving to a 6-months release cycle + immediate security fixes. My 2c Gaetano ps: in my very limited experience using the java components from the ASF for eg. an http client and logging, picking the versions of the different parts was exactly one of the sore points. I personally appreciate the very low coupling between the components even at the release level! It enables a smooth upgrade of a specific component without caring about a possible change in another one. Lot of effort is done to keep components as independent as possible between them. To some extend, they only share common best practices and the name. So why sharing a common release number? Patrick -- Patrick Allaert --- http://code.google.com/p/peclapm/ - Alternative PHP Monitor
Re: [zeta-dev] Proposal: Release process
2010/11/16 Gaetano Giunta giunta.gaet...@gmail.com: Maxime Thomas wrote: Sound strange, if we look at what is done elsewhere : - JQuery UI : shared version number - Zend : shared version number - Former eZComponents : both version number also YUI The shared version number implies a kind of packaged application. Else it can be difficult to install and maintain (same as Gaetano). Max 2010/11/16 Patrick ALLAERTpatrickalla...@php.net 2010/11/16 Gaetano Giuntagiunta.gaet...@gmail.com: Tobias Schlitt wrote: Hi Thomas, On 11/07/2010 11:55 AM, Thomas Ernest wrote: Le 04/11/2010 17:28, Tobias Schlitt a écrit : docs/release_process.txt It is a very interesting and useful synthesis. Thank you. The document summarizes the requirements for releases roughly and then tries to relealize these in a release process specific to Zeta. There are some open issues marked with notes in this document, which need to be decided on. I read the document and I focused on the two next issues (or notes) : .. note:: Incubating phase (around line 118) I don't understand what is the matter with this one. Could you tell me more please ? We are currently incubating, which means we are under deeper control of the ASF. For a release that means we need to perform 2 steps before uploading it to the servers: 1. Vote here on the list 2. Have a second vote on the Incubator PMC list Step 1 will also be mandatory once we have been promoted to be a top level project. Step 2 is only mandatory before that. I hope that made it clearer? .. note:: Determine release times. (around line 155) It seems that a full package release is a packaging of all last *stable* component releases. Hence, a full package release could be rolled automatically after every component release. We did not realize such a procedure until now for two reasons: 1. Releasing was not that easy in the eZ Components project 2. Updating the full package install is cumbersome work for users I'd pretty much love to get rid of 1 for Zeta Components, so that should not be an issue in the future. However, the full package cannot be installed automatically by users. They need to manually unpack stuff. This kind of release is pretty much useful for people who just want to take a first look and play around with the code. However, I personally would love to have such automatic package builds, as I would love nightly builds, too. It's just quite some work to realize this and we need a volunteer to take care for it. And I'm not sure if everyone agrees with my views here. So, I see full package release as a sub part of component release process, which involves that : - There is no need for release time. - There is no need for votes. That would indeed save some bureaucratic hassle, yes. :) This possibility relies on the assumption that a full package release hasn't more value-added (or worth) than sum of stable component releases. It means that there is no additional deployment mechanism in full package releases for instance. No, so far the full package releases only contained stable component versions, which were also distributed through the PEAR channel earlier. Here comes questions : A/ What is your opinion about the proposal automate full package release ? B/ What are advantages of separating full package release process from component release process ? (It should probably be my first question before writing all this stuff :-)) For A: I would love to see such a process, as said above. For B: An advantage of the previous process was, that component maintainers always tried to have features ready by a defined date, so that they can become part of the full package release. However, I think a more agile way, which allows us to release more fast and often would be nice. As an end user, sysadmin and app developer, the idea of having per-component release makes my head hurt. While I agree that a more agile build infrastructure is a bonus, as user of the library I do not need at all separate components versions released independently. How could I possibly test the new zeta-c versions, pick the ones to integrate in my projects, decide on timing of upgrades, when a new component might be released every other week? There's a reason the whole world is moving to a 6-months release cycle + immediate security fixes. My 2c Gaetano ps: in my very limited experience using the java components from the ASF for eg. an http client and logging, picking the versions of the different parts was exactly one of the sore points. I personally appreciate the very low coupling between the components even at the release level! It enables a smooth upgrade of a specific component without caring about a possible change in another one. Lot of effort is done to keep components as independent as possible between them. To some extend, they only share common best practices and
Re: [zeta-dev] Proposal: Release process
Patrick ALLAERT wrote: 2010/11/16 Gaetano Giuntagiunta.gaet...@gmail.com: Maxime Thomas wrote: Sound strange, if we look at what is done elsewhere : - JQuery UI : shared version number - Zend : shared version number - Former eZComponents : both version number also YUI The shared version number implies a kind of packaged application. Else it can be difficult to install and maintain (same as Gaetano). Max 2010/11/16 Patrick ALLAERTpatrickalla...@php.net 2010/11/16 Gaetano Giuntagiunta.gaet...@gmail.com: Tobias Schlitt wrote: Hi Thomas, On 11/07/2010 11:55 AM, Thomas Ernest wrote: Le 04/11/2010 17:28, Tobias Schlitt a écrit : docs/release_process.txt It is a very interesting and useful synthesis. Thank you. The document summarizes the requirements for releases roughly and then tries to relealize these in a release process specific to Zeta. There are some open issues marked with notes in this document, which need to be decided on. I read the document and I focused on the two next issues (or notes) : .. note:: Incubating phase (around line 118) I don't understand what is the matter with this one. Could you tell me more please ? We are currently incubating, which means we are under deeper control of the ASF. For a release that means we need to perform 2 steps before uploading it to the servers: 1. Vote here on the list 2. Have a second vote on the Incubator PMC list Step 1 will also be mandatory once we have been promoted to be a top level project. Step 2 is only mandatory before that. I hope that made it clearer? .. note:: Determine release times. (around line 155) It seems that a full package release is a packaging of all last *stable* component releases. Hence, a full package release could be rolled automatically after every component release. We did not realize such a procedure until now for two reasons: 1. Releasing was not that easy in the eZ Components project 2. Updating the full package install is cumbersome work for users I'd pretty much love to get rid of 1 for Zeta Components, so that should not be an issue in the future. However, the full package cannot be installed automatically by users. They need to manually unpack stuff. This kind of release is pretty much useful for people who just want to take a first look and play around with the code. However, I personally would love to have such automatic package builds, as I would love nightly builds, too. It's just quite some work to realize this and we need a volunteer to take care for it. And I'm not sure if everyone agrees with my views here. So, I see full package release as a sub part of component release process, which involves that : - There is no need for release time. - There is no need for votes. That would indeed save some bureaucratic hassle, yes. :) This possibility relies on the assumption that a full package release hasn't more value-added (or worth) than sum of stable component releases. It means that there is no additional deployment mechanism in full package releases for instance. No, so far the full package releases only contained stable component versions, which were also distributed through the PEAR channel earlier. Here comes questions : A/ What is your opinion about the proposal automate full package release ? B/ What are advantages of separating full package release process from component release process ? (It should probably be my first question before writing all this stuff :-)) For A: I would love to see such a process, as said above. For B: An advantage of the previous process was, that component maintainers always tried to have features ready by a defined date, so that they can become part of the full package release. However, I think a more agile way, which allows us to release more fast and often would be nice. As an end user, sysadmin and app developer, the idea of having per-component release makes my head hurt. While I agree that a more agile build infrastructure is a bonus, as user of the library I do not need at all separate components versions released independently. How could I possibly test the new zeta-c versions, pick the ones to integrate in my projects, decide on timing of upgrades, when a new component might be released every other week? There's a reason the whole world is moving to a 6-months release cycle + immediate security fixes. My 2c Gaetano ps: in my very limited experience using the java components from the ASF for eg. an http client and logging, picking the versions of the different parts was exactly one of the sore points. I personally appreciate the very low coupling between the components even at the release level! It enables a smooth upgrade of a specific component without caring about a possible change in another one. Lot of effort is done to keep components as independent as possible between them. To some extend, they only share common best practices and the name. So why sharing a common release number? Patrick -- Patrick
Re: [zeta-dev] Proposal: Release process
Why not, but if I want a set of components that includes tiein, how can I do ? Do I have to download each components separately ? My opinion is maybe to get both version numbers as it was done fore ezc, a version number for the set and a version number for each components. By this way, everyone could either download the full package or just the package they want. And honestly, I cannot see the problem of downloading all even if you don't use some parts. Who can do the more can do the less. Max 2010/11/16 Patrick ALLAERT patrick.alla...@gmail.com 2010/11/16 Gaetano Giunta giunta.gaet...@gmail.com: Maxime Thomas wrote: Sound strange, if we look at what is done elsewhere : - JQuery UI : shared version number - Zend : shared version number - Former eZComponents : both version number also YUI The shared version number implies a kind of packaged application. Else it can be difficult to install and maintain (same as Gaetano). Max 2010/11/16 Patrick ALLAERTpatrickalla...@php.net 2010/11/16 Gaetano Giuntagiunta.gaet...@gmail.com: Tobias Schlitt wrote: Hi Thomas, On 11/07/2010 11:55 AM, Thomas Ernest wrote: Le 04/11/2010 17:28, Tobias Schlitt a écrit : docs/release_process.txt It is a very interesting and useful synthesis. Thank you. The document summarizes the requirements for releases roughly and then tries to relealize these in a release process specific to Zeta. There are some open issues marked with notes in this document, which need to be decided on. I read the document and I focused on the two next issues (or notes) : .. note:: Incubating phase (around line 118) I don't understand what is the matter with this one. Could you tell me more please ? We are currently incubating, which means we are under deeper control of the ASF. For a release that means we need to perform 2 steps before uploading it to the servers: 1. Vote here on the list 2. Have a second vote on the Incubator PMC list Step 1 will also be mandatory once we have been promoted to be a top level project. Step 2 is only mandatory before that. I hope that made it clearer? .. note:: Determine release times. (around line 155) It seems that a full package release is a packaging of all last *stable* component releases. Hence, a full package release could be rolled automatically after every component release. We did not realize such a procedure until now for two reasons: 1. Releasing was not that easy in the eZ Components project 2. Updating the full package install is cumbersome work for users I'd pretty much love to get rid of 1 for Zeta Components, so that should not be an issue in the future. However, the full package cannot be installed automatically by users. They need to manually unpack stuff. This kind of release is pretty much useful for people who just want to take a first look and play around with the code. However, I personally would love to have such automatic package builds, as I would love nightly builds, too. It's just quite some work to realize this and we need a volunteer to take care for it. And I'm not sure if everyone agrees with my views here. So, I see full package release as a sub part of component release process, which involves that : - There is no need for release time. - There is no need for votes. That would indeed save some bureaucratic hassle, yes. :) This possibility relies on the assumption that a full package release hasn't more value-added (or worth) than sum of stable component releases. It means that there is no additional deployment mechanism in full package releases for instance. No, so far the full package releases only contained stable component versions, which were also distributed through the PEAR channel earlier. Here comes questions : A/ What is your opinion about the proposal automate full package release ? B/ What are advantages of separating full package release process from component release process ? (It should probably be my first question before writing all this stuff :-)) For A: I would love to see such a process, as said above. For B: An advantage of the previous process was, that component maintainers always tried to have features ready by a defined date, so that they can become part of the full package release. However, I think a more agile way, which allows us to release more fast and often would be nice. As an end user, sysadmin and app developer, the idea of having per-component release makes my head hurt. While I agree that a more agile build infrastructure is a bonus, as user of the library I do not need at all separate components versions released independently. How could I possibly test the new zeta-c versions, pick the ones to integrate in my projects, decide on timing of upgrades, when a new component
Re: [zeta-dev] Proposal: Release process
Hi guys, as far as I can see there are two major points in this discussion: 1. Providing updates for single components in short time frames could bring people to an update hell, when they need to download and upgrade some components every week. 2. The clear target of Zeta to provide components as loosely coupled as possible would be lead ad absurdum by only providing full package upgrades. I agree with both points somehow and for these reasons we basically ran the double tracked release process in eZ Components: a) Single component upgrades were only distributed through our PEAR channel b) A full package release was shipped at defined time points, containing all stable components If you as a user / admin use PEAR for your Zeta installation, frequent updates are fine, since you just need to do $ pear upgrade-all -c ezc and get all updates in place. If you don't want to rely on PEAR, you basically upgraded every half year. I don't think we should go away from this process, since it basically solves the needs of both parties. However, I see the argument for not having automatic releases of the full package whenever a component is upgraded. This would lead the argument for the full package ad absurdum. Is that convenient for everyone? Regards, Toby -- Tobias Schlitthttp://schlitt.infoGPG Key: 0xC462BC14 Want to hire me? Need quality assurance?http://qafoo.com eZ Components are Zeta Components now! http://bit.ly/9S7zbn
Re: [zeta-dev] Proposal: Release process
Hi Thomas, On 11/07/2010 11:55 AM, Thomas Ernest wrote: Le 04/11/2010 17:28, Tobias Schlitt a écrit : docs/release_process.txt It is a very interesting and useful synthesis. Thank you. The document summarizes the requirements for releases roughly and then tries to relealize these in a release process specific to Zeta. There are some open issues marked with notes in this document, which need to be decided on. I read the document and I focused on the two next issues (or notes) : .. note:: Incubating phase (around line 118) I don't understand what is the matter with this one. Could you tell me more please ? We are currently incubating, which means we are under deeper control of the ASF. For a release that means we need to perform 2 steps before uploading it to the servers: 1. Vote here on the list 2. Have a second vote on the Incubator PMC list Step 1 will also be mandatory once we have been promoted to be a top level project. Step 2 is only mandatory before that. I hope that made it clearer? .. note:: Determine release times. (around line 155) It seems that a full package release is a packaging of all last *stable* component releases. Hence, a full package release could be rolled automatically after every component release. We did not realize such a procedure until now for two reasons: 1. Releasing was not that easy in the eZ Components project 2. Updating the full package install is cumbersome work for users I'd pretty much love to get rid of 1 for Zeta Components, so that should not be an issue in the future. However, the full package cannot be installed automatically by users. They need to manually unpack stuff. This kind of release is pretty much useful for people who just want to take a first look and play around with the code. However, I personally would love to have such automatic package builds, as I would love nightly builds, too. It's just quite some work to realize this and we need a volunteer to take care for it. And I'm not sure if everyone agrees with my views here. So, I see full package release as a sub part of component release process, which involves that : - There is no need for release time. - There is no need for votes. That would indeed save some bureaucratic hassle, yes. :) This possibility relies on the assumption that a full package release hasn't more value-added (or worth) than sum of stable component releases. It means that there is no additional deployment mechanism in full package releases for instance. No, so far the full package releases only contained stable component versions, which were also distributed through the PEAR channel earlier. Here comes questions : A/ What is your opinion about the proposal automate full package release ? B/ What are advantages of separating full package release process from component release process ? (It should probably be my first question before writing all this stuff :-)) For A: I would love to see such a process, as said above. For B: An advantage of the previous process was, that component maintainers always tried to have features ready by a defined date, so that they can become part of the full package release. However, I think a more agile way, which allows us to release more fast and often would be nice. Thanks for your input! Regards, Toby -- Tobias Schlitthttp://schlitt.infoGPG Key: 0xC462BC14 Want to hire me? Need quality assurance?http://qafoo.com eZ Components are Zeta Components now! http://bit.ly/9S7zbn
Re: [zeta-dev] Proposal: Release process
Hi Tobias, Le 04/11/2010 17:28, Tobias Schlitt a écrit : docs/release_process.txt It is a very interesting and useful synthesis. Thank you. The document summarizes the requirements for releases roughly and then tries to relealize these in a release process specific to Zeta. There are some open issues marked with notes in this document, which need to be decided on. I read the document and I focused on the two next issues (or notes) : .. note:: Incubating phase (around line 118) I don't understand what is the matter with this one. Could you tell me more please ? .. note:: Determine release times. (around line 155) It seems that a full package release is a packaging of all last *stable* component releases. Hence, a full package release could be rolled automatically after every component release. So, I see full package release as a sub part of component release process, which involves that : - There is no need for release time. - There is no need for votes. This possibility relies on the assumption that a full package release hasn't more value-added (or worth) than sum of stable component releases. It means that there is no additional deployment mechanism in full package releases for instance. Here comes questions : A/ What is your opinion about the proposal automate full package release ? B/ What are advantages of separating full package release process from component release process ? (It should probably be my first question before writing all this stuff :-)) Thank you for the doc. Regards. Thomas. Regards, Toby
