On Tue, 2013-02-12 at 09:15 +0100, Heiko W.Rupp wrote:
Hey Lukas,
good points
Am 12.02.2013 um 08:24 schrieb Lukas Krejci:
> While technically, I think we have most of the questions answered thanks to
> your work, Heiko, I think a couple of questions still have to be answered.
>
> 1) If we are going to split plugins and helpers from the core RHQ, how is it
> going to affect versioning?
My proposal is that they work against a *stable* version of RHQ core.
E.g. the current 4.6-snapshot stream would work against 4.5.1 artifacts.
If the plugins need a newer version of modules/core, we would build
a new stable version of that and publish to central.
The important point here is that those modules/core artifacts (and perhaps
also dependencies for server plugins) are available from central so that a
plugin developer does not need to add some jBoss repos to his setup
in order to be able to compile them.
Another possible, but imo less desirable alternative is to publish timed
snapshots ("versioned snapshots"?) to central. We should do that only
when relevant changes are made and not on a per run or nightly basis,
as this would just pollute cental (and would probably be rejected anyway).
The plug-in version schema we are currently using doesn't make much
sense to me anyway. Why not define API versions and plug-ins require a
specific API version or version family? Then, the actual plug-in version
would be completely unrelated to RHQ core in the sense that the version
would better align with the resource it supported. For example, the
JBoss AS 7 plug-in could actually have a version of 7.x to indicate the
version of AS it was released with.
In any event, my opinion is that versions stop getting bumped just
because a new version of RHQ was released. Instead, if nothing has
changed in the JMX plug-in, then its version would remain 4.5 until we
had to commit a code change to the JMX plug-in to support an API
change.
--
Larry O'Leary
https://plus.google.com/u/0/112645929986009801513