-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Comments inline.
- -john Brett Porter wrote: | | Hi, | | I was looking over Emmanuel's Continuum release marathon today and | wondered if there were a couple of things we could do to improve the | process. | | Two things stood out for me - maybe Emmanuel can highlight the reasons | they were necessary and we can come up with some solutions. | | 1) It appeared that a component was released even though it hadn't | changed, possibly misled by the fact that the version is bumped | immediately after the last release. If it had changed, there was no easy | way for me to tell. | - solution here is really the maintenance of a changelog or changes | file, but I'd like to discuss what options we have here a little more | I'm +1 for Emmanuel's concept of performing a diff against the last tag. We could probably resolve the current project again for RELEASE version, to get the tag-name, I guess. Then, I guess you'd have to present the diff results to the user somehow, since it could affect his decision to release, or the release version to use (x.y-z vs. x.y.z, maybe). But I think it's smartest to try to go directly to the source for changes, rather than rely on a manual process for correct documentation. | 2) It seemed some releases were needed just to bump a dependency | version. This really shouldn't be necessary as the end application | should be able to select the appropriate versions it wants as long as | they are compatible (though in some cases they may not use that | dependency themselves - so do we need a new construct for that, or | should it simply be included as runtime, or something else?) I think | here we'd benefit from hearing the reasons it was necessary in continuum | or any other examples others can come up with. One that springs to mind | for me is releasing plexus-site-renderer to get a new doxia for the site | plugin. | ~From Emmanuel's reply, it seems like we might benefit from some sort of metadata maintenance process. Especially, for publishing relocations in this case... Beyond this, though, it seems like the idea of putting false dependency specifications into the end-app POM smells a little bit. However, if they're properly documented as "This should be removed when we update the such-and-such dependency version" then I guess they're the best weapon we have. Once we get conflict resolution more firmly in place, it might be nice to have a configuration element in the POM for extensions like conflict resolution. This would allow a set of "preferred" versions that the end-app could maintain without specifying a phantom dependency. Dependencies like this won't poison the build, I don't imagine...unless they specify the dependency more strictly than the next version of the upstream POM that they were originally overriding. Then, it could actually block updates to that artifact. However, whatever else they do WRT the build, they do lower the reporting value of the POM, since they're not direct dependencies. They also break encapsulation of the build, since the upstream project cannot choose to use a different implementation, and they force the end-app to have too much information about upstream dependencies. I dunno, I'm probably wandering off the mark a tad here, but those are my thoughts... - -j -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFDXlI9K3h2CZwO/4URAsABAKCqXOfxZHle0Y5dDusapU6SsinVWgCdE41c WpT1WqO4Xr5Zo1JVBzwPHlA= =u6HI -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
