incubator-zeta-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Patrick ALLAERT <>
Subject Re: [zeta-dev] Proposal: Release process
Date Tue, 16 Nov 2010 14:57:17 GMT
2010/11/16 Gaetano Giunta <>:
> 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 Allaert
--- - Alternative PHP Monitor

View raw message