I think it is safe to say that the questions surrounding moving plugins into their own
repos and versioning of plugins are more complex that questions strictly related to moving
to github. Gven that the plugin questions are not likely to be resolved as quickly,
I'd like to propose that we consider them separately from any issues that pertain
strictly to moving from fedorahosted to github. If github were to cease to exist tomorrow,
the plugin questions are still as valid as they are today.
On Feb 13, 2013, at 3:31 PM, Larry O'Leary <loleary(a)redhat.com> wrote:
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
_______________________________________________
rhq-devel mailing list
rhq-devel(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/rhq-devel