Branch 5.2.0.M1.x and tag 5.2.0.M1 can indeed not be lost.
Migrating them to the split-off repo's is not an option (see reasons
in my previous mail),
so we can just create the tag in subversion and check them in there.
Its much better than allowing the monolothic droolsjbpm to live in
the long term and cause a lot of confusion.
Op 09-02-11 20:14, Toni Rikkola schreef:
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: