Re: [zeta-dev] Proposal: Release process

[Gaetano Giunta]

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