github migration

John Sanda jsanda at redhat.com
Thu Feb 14 02:26:11 UTC 2013


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 at 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 at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/rhq-devel



More information about the rhq-devel mailing list