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 ALLAERT<patrickalla...@php.net> > >> > >>> 2010/11/16 Gaetano Giunta<giunta.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 > >>> > > 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! >
