----- Original Message -----
From: "Heiko W.Rupp" <hrupp(a)redhat.com>
To: rhq-devel(a)lists.fedorahosted.org
Sent: Friday, March 1, 2013 8:10:49 AM
Subject: Re: GitHub migration again -- The Plan
Am 01.03.2013 um 14:20 schrieb Thomas Segismont:
> With split repositories, for this particular case, I would like to
> be able to make one commit to the core, make a minor release and
> then update the plugins in other commits to their respective
> repositories).
Right.
And then there is no need in this case to immediately create a new
release/timed snapshot, but your change in the plugin code can be
stashed
for a few days. This would allow to batch up changes and prevent
churn in the modules/core releases.
I am not sure how this would work from the perspective of getting a build out for testing
purposes. The fix for core might break something else in the plugins space but there is no
way to get feedback for the change in core until post-release of core itself. Since the
test driver in this case would be a change or new functionality in a plugin, nothing can
be tested with just a core release. The only way to test the change is to have the plugins
consume a new release of core.
And what is the recourse if the fix in core is deemed bad (which will happen)? Release
another version of core and go through the same process? The need to re-release core will
add considerable delays between the time a fix is available and the actual testing for the
fix to occurs.
Thank you,
Stefan Negrea
_______________________________________________
rhq-devel mailing list
rhq-devel(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/rhq-devel