>
> On Apr 19, 2010, at 03:53, jacek_at_smars.pl wrote:
>
>> Ok, it seems to be ok but has some disadvantages:
>>
>> when I commit changes on either trunk, this change is made only on
>> /share/module_1234 (the revision number of project1 or project2 will not
>> increase).
>> Because of the above there is no information in show log of
>> project1/project2.
>
> I guess you have each project in its own repository? Ok.
Actually all projects are in single repo but I wonder about making them
separately (are there any advantages of it?)
>
> The strategy is that each project, and each module, has its own release
> schedule. So if you make a change to module_1234, then you release (i.e.
> tag) a new version of module_1234. And then, as a second step, for each
> project that uses module_1234, you update that project to use that new
> version of that module. This implies that the external defined in each
> project does not refer to the module's trunk but to a tag of that module.
> So at minimum you'd update the external definition to point to the new
> version of the module. Possibly, you'd also need to make other changes to
> the project, if you've changed the module's interface or added new
> functionality to the module that you now want to use in the project.
>
In my approach:
Any changes to any module in the tunk does not mean a release of the new
version (I do not create any tag after each commit to the trunk)
Trunk is being "stabilized" until it is buildable and simple tests are
passed.
Then I release such trunk by making a branch or/and tag.
If the build fails(or some test wont pass), I can do a simple show log on
trunk of such project and see who broke it.
not sure if it is the optimal way...
>> The trunk history of the latest changes is very handy.
>> Also any commit to the trunk should trigger the auto build, and in these
>> case it won't. (unless the /share/ is also watched by the auto build
>> tool,
>> which is actually not a problem)
>
> Also solved by the above since now there is a commit in the project's
> repository whenever you switch to a new version of the module.
>
Received on 2010-04-19 11:37:07 CEST