github migration

Larry O'Leary loleary at redhat.com
Wed Feb 13 20:31:45 UTC 2013


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



More information about the rhq-devel mailing list