workplan and branching strategy

Dear all,

In short term (4-6 weeks?), we need to upgrade both the parser and
kernel to Release 1.0 in the current coding style. The work can be
divided into two parts: 1. parser + AOM update; 2. RM update. It is
possible for two teams take one task each and don't have too much
dependency on each other. It seems to be good for these two teams
working on separate branches.

So here is my proposal:
1. The release-0.95 branch will receive no further development except
bug fixes.
2. I make a new branch for updating RM towards Release 1.0 probably
under the name of Release-1.0. I assume the UCL team will be working on
that and can start to commit changes after the branch is created.
3. I continue to work on the trunk and make update of the RM and parser.

From time to time, I merge newly updated RM classed from Release-1.0

branch back to the trunk and make sure the AOM and parser still work.
4. After all the updates are done and tested, copy the trunk to
Release-1.0, make a tag and declare a public release.

Any comment ?

As soon as we agree on this, the new Release-1.0 branch will get created
and the UCL team and I can start to commit changes.

Cheers,
Rong

Dear all,

In short term (4-6 weeks?), we need to upgrade both the parser and
kernel to Release 1.0 in the current coding style. The work can be
divided into two parts: 1. parser + AOM update; 2. RM update. It is
possible for two teams take one task each and don’t have too much
dependency on each other. It seems to be good for these two teams
working on separate branches.

So here is my proposal:

  1. The release-0.95 branch will receive no further development except
    bug fixes.
  2. I make a new branch for updating RM towards Release 1.0 probably
    under the name of Release-1.0. I assume the UCL team will be working on
    that and can start to commit changes after the branch is created.
  3. I continue to work on the trunk and make update of the RM and parser.

From time to time, I merge newly updated RM classed from Release-1.0

branch back to the trunk and make sure the AOM and parser still work.
4. After all the updates are done and tested, copy the trunk to
Release-1.0, make a tag and declare a public release.

Any comment ?

The UCL team is happy with the suggestion. Could you please have the branch created as soon as possible?

Yin Su Lim wrote:

Dear all,

In short term (4-6 weeks?), we need to upgrade both the parser and
kernel to Release 1.0 in the current coding style. The work can be
divided into two parts: 1. parser + AOM update; 2. RM update. It is
possible for two teams take one task each and don't have too much
dependency on each other. It seems to be good for these two teams
working on separate branches.

So here is my proposal:
1. The release-0.95 branch will receive no further development except
bug fixes.
2. I make a new branch for updating RM towards Release 1.0 probably
under the name of Release-1.0. I assume the UCL team will be working on
that and can start to commit changes after the branch is created.
3. I continue to work on the trunk and make update of the RM and parser.

From time to time, I merge newly updated RM classed from Release-1.0

branch back to the trunk and make sure the AOM and parser still work.
4. After all the updates are done and tested, copy the trunk to
Release-1.0, make a tag and declare a public release.

Any comment ?

The UCL team is happy with the suggestion. Could you please have the
branch created as soon as possible?

It's done!