incubator-zeta-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gaetano Giunta <giunta.gaet...@gmail.com>
Subject Re: [zeta-dev] Proposal: Release process
Date Tue, 16 Nov 2010 15:59:06 GMT
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<patrickallaert@php.net>
>
>> 2010/11/16 Gaetano Giunta<giunta.gaetano@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
>>


Mime
View raw message