We don't really need the 5.2.0.M1.x branch if we have the tag, but I have a feeling that we will lose that one too.
We don't usually need the minor release branches or tags after the release, but they are nice to have. The M1 is codes are saved in the src.zip in our downloads page. So if somebody needs them they can get them from there.
Toni
On Feb 9, 2011, at 6:34 PM, Michael Anstis wrote:
Where will 5.2.0.M1.x live?
It won't be put back into SVN nor will it be migrated as part of the split-up.
Does this mean 5.2.0.M1 will be lost forever and we'll effectively re-branch after the split-up is complete to give a 5.2.0.Mx?
Given 5.2.0.M1 hasn't been officially announced I wonder whether it'll be most pragmatic to re-branch 5.2.0.M1 after the split-up and announce that as the M1 release? Or we skip straight to M2?
It's impossible to meaningfully migrate the branches into the
split-off repositories.
The reasons are:
1) the build on those release branches won't be able to cope with
being split-off, unless I manually fix them one by one (= big
changes, very impractical)
2) the git command to split-up the repository doesn't support it if
a split-off repositories contains multiple directories.
So, branches/tags will not be migrated to the split-off
repositories.
All history of master will be migrated.
The 4 topic branches (lr_unlinking_20101116, ...) will need to be
manually migrated by their owners. Sorry.
The monolithic droolsjbpm git repository will be kept around for a
short time to give them the time to do this.
The 5 community release branches (up to 5.1.x) will be moved back to
subversion (to rejoin their SOA release branch brothers),
so we can remove the monolithic droolsjbpm git repository before it
causes to much confusion.
The community release branch 5.2.0.M1.x will be lost.
HTH
Op 07-02-11 13:06, Geoffrey De Smet schreef:
Hi guys,
I 'll be doing some changes that will force you to delete your
git working directory and all your git forks.
I am sorry to put you through this, but it will make development
life better afterwards.
Contact me if the dates don't work out for you. Suggestions, ideas
are still welcome of course.
Please forward this message to any droolsjbpm developer not
reading the mailing list.
Please do not make any build changes in the next 2 weeks,
because those changes might be lost.
Mail me the build changes and I 'll do them for you and make sure
they aren't lost.
What will change?
We ‘ll
split up the monolithic droolsjbpm repository into a few
smaller repositories.
We will preserve history per repository.
The droolsjbpm repository will be retired but
not deleted.
Your guvnor clone won’t take 1.2 GB diskspace
anymore.
We ‘ll
split up the monolithic build into a few smaller builds (one
per repo).
You’ll be able to build/test just guvnor.
Even
if drools-core doesn’t build/test.
We ‘ll
split up the monolithic hudson job into a few smaller jobs
(one per repo).
If the drools-eclipse guys break a test, the
guvnor job will still be blue (and vica versa), only the
drools-eclipse job will be red.
The build will be broken less and the cause
will be easier to identify and fix.
Hudson won’t be red all the time anymore.
We ‘ll
make some directory name changes, so artifactId’s are less
confusing and more correct
For example: drools-server (which has nothing to do with the guvnor
server) will be renamed to drools-camel-server
We ‘ll
clean up some general things, like file endings, etc
New repository’s
We will end up with these repositories after the
split-up is completely done: