Antonio Gallardo wrote:
Ralph Goers dijo:
Sylvain made it pretty clear that snapshots wouldn't be used in formal
Cocoon releases, so this procedure would never apply to those. In the past
this hasn't been followed.
I disagree. Contrary to what you wrote. The rule was followed as long as
we can. We try the most we can to stick to a released version. If you
compare the lastest cocoon releases with older ones, you will see that we
are distributing more released jars than before.
That's why this source-preservation thing only applies to very exceptional cases where we need a fix in a 3rd party library that's not yet included in an official release.
Of course, this no a 100% applied rule to all jars, because some jars takes longer or have diferent cycles of releases. As a sample take the jexl. They never released a version. What we do is just to bundle a CVS version of that. And we stick to them as longer as we can.
And yes, there are some exceptions to the rule. We use "common sense" while deciding when we can broke this rule. Sample:
When an important bug is fixed on a 3rd party jar (from our POV) that has a current released version that seems to be important to us, we can repleace it with a CVS version that include the fix. Of course we often ask to the list. A lazy vote is done before updating it.
If that happens in the future I would want the snapshot
source with the release.
Already was told that a date with minute precision is enough to get the
right code from a CVS. If I ned to choice between adding 8-bytes to a jar
name and adding 500 kB into the same jar. I prefer the 1.
Considering how discussion goes around this problem, I'm starting to consider David's proposal as the only compromise that will stop these useless frictions.
As a Cocoon user I really don't care if the problem is at x line inside a
3rd party lib. To me is enough to know that the fuunction f() in the 3rd
party lib is not making the right work. How the function f() works it is
up to the 3rd party jar developers.
C'mon Antonio! As a software developper, your goal is to build an application that works. And if you depend on that f() function and need to release to the customer, you will certainly get your hands dirty in the 3rd party code. That's one of the biggest advantages of opensource: you can fix it yourself.
If people really care, we will had fixed all the problems in xalan, xerces and so on. And AFAIK, they have a big bug list now. They use Cocoon (or Xalan, Xerces and expect that the right community fix it). I understand this POV, because there is people with more experience than "this" user that can fix the bug without breaking other parts of the system.
Now, the more experienced users (and developers?):
They already have a lot of related project in the hard disk. They have the
sources on the disk. They care to go into the f() function and discover
why it does not work as expected. This kind of users are very few. I can
include myself here. I have lot of sources of 3rd party jars in the PC. If
I choose to follow the 3rd party jar, I prefer to follow it in the right
community and tell them if there is a problem and perhaps how to fix it.
Who said the contrary? Nobody ever talked about forking 3rd party libraries!
Also is important to note that, Cocoon often is ranted because our
distribution is bigger than the any J2SDK! And adding java files to 3rd
party libs will dramatically increase the size of the distrbution. This
will be a really bloat to us.
Again and again and again: THIS IS ONLY ABOUT SNAPSHOTS OF 3RD PARTY LIBRARIES, AND THEREFORE MOSTLY BETWEEN COCOON RELEASES AS WE TRY AS MUCH AS POSSIBLE TO USE RELEASED VERSIONS OF 3RD PARTY LIBRARIES FOR OFFICIAL COCOON DISTRIBUTIONS.
So yes, the *cvs update* size may be bigger. But not the official distro.
Sylvain, getting bored.
-- Sylvain Wallez Anyware Technologies http://www.apache.org/~sylvain http://www.anyware-tech.com { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
