… and I did the first web application using it, now I’m going to create the second.
In this first web application I enhanced the framework’s core library with new things and promptly updated framework branch.
I’m using bazaar to keep framework and web application committed. The application was in the beginning, a full branch of framework source tree, now I’m updating framework manually at every change on core files. (copying changed files from web app to framework’s branch).
With this second web application that I’m going to create, I need to know about versions (or revisions) which the application is based. If I found a bug in this version I can fix and then sync files with first web application no worrying: functions will be the same to this application.
If I’m going to make changes in core (new behavior, new functions in library or something new in source tree) it must be named as “new version”.
What’s the best way to do this?
Because I’m using a Distributed Version Control System (bazaar), I’m not dealing with VERSIONS, but revision numbers that change every time.
Please fresh my mind with new ideas.
I would organise all these apps in their own repositories:
1) Your framework code, where you then release constantly different versions: 1.0, 1.1, etc.
2) Web app 1, where you plugin your framework-component version x.y.z
3) Web app 2, where you plugin your framework-component version x.y.z
If now WebApp1 needs a new feature, you implement this in your framework-code and then you release a new version, or maybe you first collect some changes which you want then to integrate into your WebApp1 and after that you make a new framework release.
With this you can easily say WebApp1 is dependent on the framework code version 1.0 and maybe the WebApp2 is dependent on a newer framework code for example version 1.2.
Important is, that you can integrate your framework code as “component” or “plugin” to your webapps. Then you can easily replace the framework code with newer ones.
I hope I had understand your question.