Patrick ALLAERT wrote:
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?
Nobody forces you to do so:
. get the latest version of the full package
. read release notes of 2 components
. decide which components to update in your case (0 to 2)
. copy the updated versions over to your app
PEAR nor PECL does provide a shared version number for all the
packages they have, it would be a non sense!
These are not libraries, just repositories for people to upload their stuff to!
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!
It seems we have divergent opinions.
I will not continue this discussion further, as it is slightly ot.
But think about this: why is eZ Publish bundling the whole of the ZetaC when it
only uses a couple of components?
What if eZP extension "A" I develop uses+bundles component X version 1.2.1, but extension "B" you develop uses+bundles component X version 1.2.2? The end user
could not then install those two extensions at the same time. With a 6 months release cycle, both you and me have time to update our extensions to use in fact
version 1.2.0 of component X, which is the version delivered with eZP, and rest assured that every end user will have no problem in installing it for a while.
I vote for a release cycle that includes both single-component releases and
full-set packaged releases.
Bye
Gaetano
