On Fri, 2002-04-05 at 13:19, John McNally wrote: > As I was the one that checked in the latest beanutils that started this > can I ask what was broken? You say it was because it used > commons-logging but I updated that as well. I did check that it did not > break stratum, torque, fulcrum and t3. And the reason I updated was > that I knew at that point that the head of beanutils would work for > these packages, I did not know whether any other revision would work. > > Since there several versions of beanutils, it makes sense to me that the > commons-beanutils.jar filename would refer to the latest code.
The latest released code? Or the latest code in CVS? This is the problem I have in sticking dev snapshots in the repository. If there are issues that have been resolved in a package then the producer of that package should pushed to do a point release. Can you imagine having a 1000 different packages in the repository where there was a development snapshot of any given number of those packages? I think things would fall apart pretty quickly because no rigor is required to push up a JAR that was built from CVS. > Are you > saying an unversioned filename should always refer to the latest > released version of a library? No. For the commons-beanutils JAR the name it has is the name that its build process produces. When I rename everything according to the version document and Sun's guidelines it will be commons-beanutils-1.0.jar (or whatever it's at). > If so I propose we use the convention > commons-beanutils-HEAD.jar or commons-beanutils-dev.jar to mean the > library built from the latest cvs. I guess I did not follow the > decision process on unversioned filenames, what was the conclusion (if > it is a simple one liner)? I'm not sure about the exact details of how the repository is going to work, but I would like to promote a stringent form of versioning that is specified in the <dependencies> and the promotion of using releases and making more of them when necessary. So either the JAR would have the version in it or a directory structure following the versioning conventions with versionless JAR names. I would like to start with versions in the JAR names because that's easier. With Maven if the structure changes users won't be affected. > The solution above is simpler than going to cvs, though that might be a > good idea. In my proposal, if a project chooses to use the c-b-dev.jar > (or c-b.jar whichever is decided means HEAD code), then it is that > projects' responsibility to fix any breakage due to someone else > updating the repo. If that JAR is released version and there has been proper deprecation but I don't think this would be good for dev snapshots. If I follow a project can put a JAR in the repo and everyone is forced to update their source? > It is a good idea to email the list noting that a > dev jar has been updated, though with all the lists and the fact that it > could be breaking an outside app, I do not see how a developer updating > the dev jar can be expected to know exactly where to note the change. That's the whole problem with dev JARs, no rigor. I think a build system that accommodated building from CVS would be better for the situation that we typically work in and pushing for more point releases is better then putting dev snapshots into the repo. Who are the clients for dev snapshots? Aren't the same clients going to be able to build from CVS (say Scarab developers)? If they aren't then I'm willing to be that those clients (Scarab users lets say) would be far more interested in a point release. > john mcnally > > -- jvz. Jason van Zyl [EMAIL PROTECTED] http://tambora.zenplex.org -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
