![]() |
Telelogic SYNERGY (steve huntington) | ![]() |
Topic Title: Switch to next release: previous release invisible? Topic Summary: Created On: 24-Jan-2007 10:03 Status: Read Only |
Linear : Threading : Single : Branch |
![]() |
![]()
|
![]() Answer: The following sounds like a likely explanation: A) It is expected that you will have created a baseline identifying the "final" state of the previous release before you update the project(s) for the next release. You would then have a fixed definition of the previous release for when you need to go beck. B) Further development is expected only against the next release; support of the previous release is an exception. C) Therefore all developers' projects and all build-managers prep projects just need to have the release value changed to move development on to the next release (assuming that you have defined the reconfigure templates for the next release). This uses the same projects and should use the same work-area. D) If a new work area is created, it sounds to me like you also changed the version of the project. The work area name is a combination of the project name and the project version. E) If you want to patch the previous release, then you would need to create a new project (copy project) so that you can manage the parallel development of the main-stream and the support of earlier version. This applies both to prep projects and to developer's projects. In my processes, the baseline created at A) has its version set to match the version of the release. The prep project for the mainstream development has a version of "dev", which indicates it is the on-going development state; baselines are taken using the in-built Baseline features. When we make changes to a previous release, the version of the prep project is of the form " [version]_dev ", where [version] is the version given to the release. | |
![]() |
|
In the tutorial "How to switch to the next release" it is mentioned that one should only change the properties of the project and not to copy the project. I have done this and the result is that I get a new workarea directory. The old directory is maintained. Why is this new copy of the directory made?
![]() When I execute a query to find all projects, the project with the previous version is not on the list anymore. This would mean that it would be impossible to make a patch for the previous release or am I wrong? ![]() Can anyone explain this to me? Andre |
|
![]() |
|
![]() |
|
The following sounds like a likely explanation:
A) It is expected that you will have created a baseline identifying the "final" state of the previous release before you update the project(s) for the next release. You would then have a fixed definition of the previous release for when you need to go beck. B) Further development is expected only against the next release; support of the previous release is an exception. C) Therefore all developers' projects and all build-managers prep projects just need to have the release value changed to move development on to the next release (assuming that you have defined the reconfigure templates for the next release). This uses the same projects and should use the same work-area. D) If a new work area is created, it sounds to me like you also changed the version of the project. The work area name is a combination of the project name and the project version. E) If you want to patch the previous release, then you would need to create a new project (copy project) so that you can manage the parallel development of the main-stream and the support of earlier version. This applies both to prep projects and to developer's projects. In my processes, the baseline created at A) has its version set to match the version of the release. The prep project for the mainstream development has a version of "dev", which indicates it is the on-going development state; baselines are taken using the in-built Baseline features. When we make changes to a previous release, the version of the prep project is of the form " [version]_dev ", where [version] is the version given to the release. Edited: 29-Jan-2007 at 13:34 by michael Barnes |
|
![]() |
|
![]() |
|
Thank you for your explanation. It is all clear to me now. I had changed the version of the project instead of the release.
|
|
![]() |
FuseTalk Standard Edition v3.2 - © 1999-2009 FuseTalk Inc. All rights reserved.