I think this should be a group switch, for all VFS dependant project, not just jboss-cl.

Or why just jboss-cl?

I guess I don't see any reason it has to be just jboss-cl.  The problem is there are a lot of VFS dependent projects and it is becoming a difficult to manage all the branches, so I was trying to see if there was a way we could chip away at getting them on the trunk as the projects we more and more stable with the VFS3 integration and an based on dependency order, jboss-cl was the next likely candidate.

I think we should just set a reasonable date when we're gonna change them all at once.

We give devs time till then - properly warn/promote this date.

Then branch previous stuff to right branch versions, and move VFS3 stuff to respected trunks.

Wrt jboss-cl, I know Adrian is currently working on some OSGi support, so might not be the best time to "sweep the rug under his feet". :-)

Below is a list of all the dependent projects that are used by AS.  There may even be a few more that I haven't come across.  Feel free to add any additional you can think of.

 

http://community.jboss.org/wiki/VFS3MigrationStatus

I don't see Seam-int there:

* http://anonsvn.jboss.org/repos/jbossas/projects/jboss-seam-int/trunk/

Although we need to check how much of VFS usage should be there once you move to VFS3.

It might be that we won't need it anymore -- due to more standard URL, paths, ...

I'll think about it if there are some others we missed.

alesj wrote:

 

I think we should just set a reasonable date when we're gonna change them all at once.

We give devs time till then - properly warn/promote this date.

Then branch previous stuff to right branch versions, and move VFS3 stuff to respected trunks.

From a logistical point of view, the ideal time to do this is immediately after the tag of AS 6.0.0.M2[1]. So, say some time between Feb 11 and 15, depending on how M2 goes.

However, the integration cutoff for M2 is Jan 31. After that date, work on M2 should be restricted to AS trunk itself. So that leaves a 2 week window where work can be done on external projects.

[1] Actually, probably after the branch, not the tag. I'd prefer to branch then tag, so any QE work for the release can be done against the branch, allowing trunk to be reopened quickly to development.

bstansberry@jboss.com wrote:

 

So, say some time between Feb 11 and 15, depending on how M2 goes.

Just to clarify: work on this on AS trunk would start some time between Feb 11 and Feb 15, not necessarily be completed in that window.

To follow up to my last post, I would like to attempt a somewhat controlled an order migration.  Is it possible to go one at a time, or do the MC projects have to go all at once?

No, not all at once, but in dependency order.

e.g. VFS -> CL - > Deployers -> OSGi ... others probably all go after Deployers as well

We will need a proper release of them all, at least of the dependecies -- leaves don't need to be tagged/released.

(it's mostly gonna be 2.2.0.Beta1)

Let's now settle on a date, which will be the deadline after which all trunk work for all involved projects must halt for a while.

I suggest 16th Feb, as it gives us enough time to finish whatever we have, and it's not on the first day of the week.

Once we agree, I'll send an announcement on the needed mls. OK?

Any reason we can start moving forward with creating an alpha release for VFS as it is already on the trunk?

Sure, with VFS there is np.

I/we need to check with Adrian if he has some open (aka not commited) CL stuff.

And I'll check my deployers and mc-scan work, if it breaks with VFS3.

Ok I will start working on an Alpha release of VFS.  Anything you do other than the normal maven release tasks?

Mvn release tasks are tricky.

They mostly work, but when they don't, there is no way you can understand what's going wrong.

In that case, DML has some instructions on the wiki. :-)

But yeah, "mvn release:prepare" and "mvn release:preform" is all I do.