Ace or project files

Bert Verhees wrote:

OK, I misunderstood, maintaining the 0.95 version should be done in the BRANCHES while the TRUNK only is to move forward (to 1.0).

But what is the development goal of the TRUNK then at this moment.
Because there is BRANCHE-work at the 1.0 version, will that be moved to the TRUNK at a certain moment?, and at a certain moment be copied back?
  

merged into the TRUNK, but maintained on its branch as well. That branch will then become Release 1.0 (actually, we have to make it 1.0.1); the TRUNK will then continue on, and continue to spawn new branches.

Or will the TRUNK be moved back to the BRANCHE, ro wil,l they both undergo a painful process of merge.
Are there two different working-trails toward 1.0 (The TRUNK and BRANCHE 1.0)
Isn't it too early to have a BRANCHE 1.0 release?
  

well actually I would have done it a bit later, but it doesn't matter that much.

It is confusing

II have my doubts for several reasons

- the arrows in the documentation (CM_plan.pdf) point in the wrong direction, the text in Figure5 page 19 explain that the fixes are made in the BRANCHE and after that applied to the TRUNK. This is the situation at this moment.
- at the same time the same documents explains at page 17 that the TRUNK is the mainline current development and the BRANCHES is for branche development or test work.
I would understand the terminology "branche development" as:
The BRANCHE is to freeze a certain TRUNK-situation, and after that, for offering a place for maintaining a certain (major) release, it is not a place for growing towards a new release
  

that all depends. In the specification that is exactly what we do, since we merge all changes from a candidate release branch back to the trunk, then tag the release.

When you apply these rules to 0.95, it works like it should, more or less (0.95 should be patched, you are right) but applied to 1.0, I am really confused, what is the main 1.0 version workline, when do we have a 1.0 release which is ready for production, how can we recognise this version in SVN, because at this moment, we have two version which are both in pre-beta-condition. I think the BRANCHE-1.0 should have another name
  

I wouldn't worry so much about it at the moment; this branch is simply acting as a 1.0 candidate. The changes there will go back onto the trunk when they are ready. Admittedly they haven't done it exactly as I would have done it but it will work more or less the same. BUt I agree that the Java group needs to be a bit more careful about how it is documented.

- thomas

Thanks Thomas,

It is not that I want to be picky about things, although it can look like
that. But I want to be sure that I understand the procedures well, so I can
make the right decisions.

Regards
Bert Verhees

Bert Verhees wrote:

Thanks Thomas,

It is not that I want to be picky about things, although it can look like
that. But I want to be sure that I understand the procedures well, so I can
make the right decisions.

I would not say you are are being picky Bert. There really should be
better control over the development process.

My recent experience with Java developers is that it is okay to be
sloppy and then fix it later. They use the nice term, "refactor" for
cleaning up their previous messes........ Seems this is what is being
taught now in CS classes. Arrrgggggh!

Tim