Sound strange, if we look at what is done elsewhere : - JQuery UI : shared version number - Zend : shared version number - Former eZComponents : both version number
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 ALLAERT <[email protected]> > 2010/11/16 Gaetano Giunta <[email protected]>: > > 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 >
