You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Brett Porter <br...@apache.org> on 2005/10/24 18:05:57 UTC
thoughts on release process in general
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
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.
Looking forward to hearing your thoughts on these.
Cheers,
Brett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: thoughts on release process in general
Posted by Brett Porter <br...@apache.org>.
Jason van Zyl wrote:
> If the production of a JAR was in fact unchanged then I agree that it
> should not be release again. If that's the case then it would be a best
> practice to document this but you can't rely on this as sometimes people
> just won't document things. What if the md5sum for the last release
> still holds true for the JAR produced? If the md5sum is the same then
> it's not a candidate for release. The POM is packaged up in every JAR so
> even if the POM changed the md5sum would be different. I guess we need
> to decide if a change in the metadata is grounds for a release. At first
> blush I would say yes.
Metadata changes are probably what the -1, -2 increments were designed
for - ie nothing has changed, but its being rebuilt anyway.
The md5sum is an interesting idea, but would fall down in some ways -
for example if a different version of Maven was used to build it it
might change even if the original didn't change (though I guess the
justifies a new version, it doesn't indicate to the user much about what
changed). Some invocation of clirr might be better (actually, we could
use these together to ascertain whether it is different and to what extent).
> And you needed to do this just to get a new version with some fixes or
> because the APIs changed? If there were no API changes and just fixes
> wouldn't the proper use of ranges (and possibly some conventions) allow
> for this?
Yes, ranges would solve this. The APIs didn't change - so the code
didn't change. This was purely a POM change.
What we need to push towards is what I'd originally intended - that
versions specified are "soft" versions, and the latest matching any
discovered ranges would be used under the default conflict resolver.
Unfortunately conflict resolution fell off the 2.0 feature list and for
greater predictability we reverted back to "use nearest" resolution.
So we need to greater document and encourage ranges at this point and
work on this as a 2.1 feature for sure, I was just wondering if there
were any other thoughts on the matter.
Let's start to adopt ranges on our own code so we can gather better
experience with working with them.
- Brett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: thoughts on release process in general
Posted by Jason van Zyl <ja...@maven.org>.
On Mon, 2005-10-24 at 09:05 -0700, 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
If the production of a JAR was in fact unchanged then I agree that it
should not be release again. If that's the case then it would be a best
practice to document this but you can't rely on this as sometimes people
just won't document things. What if the md5sum for the last release
still holds true for the JAR produced? If the md5sum is the same then
it's not a candidate for release. The POM is packaged up in every JAR so
even if the POM changed the md5sum would be different. I guess we need
to decide if a change in the metadata is grounds for a release. At first
blush I would say yes.
> 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.
And you needed to do this just to get a new version with some fixes or
because the APIs changed? If there were no API changes and just fixes
wouldn't the proper use of ranges (and possibly some conventions) allow
for this?
> Looking forward to hearing your thoughts on these.
>
> Cheers,
> Brett
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
--
jvz.
Jason van Zyl
jason at maven.org
http://maven.apache.org
We all have problems. How we deal with them is a measure of our worth.
-- Unknown
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: thoughts on release process in general
Posted by John Casey <jd...@commonjava.org>.
-----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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: thoughts on release process in general
Posted by Emmanuel Venisse <em...@venisse.net>.
I've done a lot of release today for use the same groupId in plexus deps
(org.codehaus.plexus). This strategy avoided me managing a great number of exclusions in
continuum dependencies. I thought one of these depdencency wasn't release since the
groupId change in all plexus components.
Perhaps we can integrate a scm diff in the release plugin between the current code and the
latest tag for check if we have some modifications in code and in pom.xml
Emmanuel
Brett Porter a écrit :
>
> 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
>
> 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.
>
> Looking forward to hearing your thoughts on these.
>
> Cheers,
> Brett
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org