github migration

Lukas Krejci lkrejci at redhat.com
Thu Feb 14 10:03:23 UTC 2013


While the location of the code and its versioning are basically orthogonal 
problems, IMHO, drawing the "repository boundaries" in our codebase is a very 
strong suggestion of the essential independence of the pieces and hence hints 
strongly at the intended versioning strategy.

That's why I wanted to bring it up while we're thinking about the migration 
and the possible split. Because it can help us define the proper "demarcation 
lines". That does not mean that we need to solve the versioning problem before 
we do the migration though. 

In fact, I think it would be perfectly fine to decide that we won't do any 
versioning changes atm and just jump a ship to github. I just think it should 
be an informed jump in the sense of the future direction ;)


On Wednesday, February 13, 2013 21:26:11 John Sanda wrote:
> 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.
> 
> _______________________________________________
> 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