2010/11/16 Gaetano Giunta <[email protected]>: > 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 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 >>>
I wouldn't consider to follow a project like ZF in terms of best practices! One of a webapp I maintain uses the following components only: Archive 1.2.4 and Cache 1.5. Should I really upgrade an application with both an up-to-date version when they are all stable? Or even worse: including everything? PEAR nor PECL does provide a shared version number for all the packages they have, it would be a non sense! I consider the per-component release of the Zeta Components as one of the greatest point in the management of reusable components! Defining dependencies on a set of different and unrelated components is the root of configuration management evil!
