Author Topic: DB3 Versioning  (Read 4286 times)

Offline Cyberduke

  • Bot Builder
  • **
  • Posts: 88
    • View Profile
DB3 Versioning
« on: October 01, 2008, 01:35:01 PM »
Since there are now going to be separate and distinct modules, in particular DNA and Physics modules can I suggest that there should be 2 published version numbers:
  • The DNA Version; which tries to change as infrequently as possible, only changing if there has been a breaking change to the DNA language or a universal change to the physics/simulation that would alter the behaviour produced from a given piece of DNA code.
  • The Application Version; which is an aggregate of everything else, for example new optional features or graphical enhancements etc.
This would allow people to better identify if the bot they have just downloaded will work as intended with the version they have.

Offline Numsgil

  • Administrator
  • Bot God
  • *****
  • Posts: 7742
    • View Profile
DB3 Versioning
« Reply #1 on: October 01, 2008, 01:53:17 PM »
That's a good point, but I want to avoid possibly confusing people, and two version numbers might be potentially confusing.  Let me think about it for a bit...

Offline Cyberduke

  • Bot Builder
  • **
  • Posts: 88
    • View Profile
DB3 Versioning
« Reply #2 on: October 01, 2008, 02:25:33 PM »
Well if the two were truly modular it also benefits a potential system whereby people could retain use of a particular version of the DNA language for whatever reason but who also want the latest GUI/Networking/Bug fix/Feature Enchantment in the latest release of the application.
« Last Edit: October 01, 2008, 02:32:51 PM by Cyberduke »

Offline Numsgil

  • Administrator
  • Bot God
  • *****
  • Posts: 7742
    • View Profile
DB3 Versioning
« Reply #3 on: October 01, 2008, 02:56:05 PM »
Okay, thought about it

Most modules probably will go through a development cycle like any other software.  So it might be that I want to release the latest stable versions of physics and DNA, etc.  And it might be that the latest stable release for physics is from 3 months ago, and the latest stable version of DNA is from two weeks ago.  So I think what we should do is maintain major version numbers on all modules, but combine them together for a final version.  So for instance Darwinbots 3.22 might contain Sunweaver 1.2 and Physics 0.8, or whatever.  You, as an end user, probably won't ever see or care about module versions, but advanced users can hotswap modules (maybe use the new experimental physics module) if they need or want to.

That's my present thinking anyway.  That'll hopefully avoid issues with fixing a bug in physics and introducing a bug in DNA in the same commit.  But it probably requires me reorganizing the project files and modules a bit more to allow branching and tagging on the module level.  Ugh, that might become messy.  Any ideas?  I'll go google for some info.

Offline Cyberduke

  • Bot Builder
  • **
  • Posts: 88
    • View Profile
DB3 Versioning
« Reply #4 on: October 01, 2008, 03:13:53 PM »
Yes...
If the modules (assemblies) are going to be totally independent then they should probably have their own SVN trunk and branch structures, they can still come together in the same VS Solution. I think that’s what you meant

Edit:- You would want to build a solution file for each release version though. Other than that they are probably big enough sections of code and so isolated that you would probably only be working on one at a time.

Although I still feel the two important distinctions for me as a user are things that affect the way my DNA code behaves and those that don’t.

* hot swappable implies to me that it can be done while the application is up and running, which of course we can do easily enough via a drop down menu etc. Just unload one assembly and load in the new one. But is that what you meant?
« Last Edit: October 01, 2008, 03:16:51 PM by Cyberduke »

Offline Cyberduke

  • Bot Builder
  • **
  • Posts: 88
    • View Profile
DB3 Versioning
« Reply #5 on: October 01, 2008, 03:21:40 PM »
In fact maybe the solution files shouldn’t go in the SVN altogether, since that would allow me to use VS2008 and just put whatever collection of modules in my solution I wanted. And if someone wanted to use a different IDE they could, Framework 2.0 code is still Framework 2.0 code


Edit:- Ah this will screw up Nunit... and XNA... bad idea, abort abort.
« Last Edit: October 01, 2008, 03:35:14 PM by Cyberduke »

Offline Numsgil

  • Administrator
  • Bot God
  • *****
  • Posts: 7742
    • View Profile
DB3 Versioning
« Reply #6 on: October 01, 2008, 04:27:22 PM »
Quote from: Cyberduke
Yes...
If the modules (assemblies) are going to be totally independent then they should probably have their own SVN trunk and branch structures, they can still come together in the same VS Solution. I think that’s what you meant

Edit:- You would want to build a solution file for each release version though. Other than that they are probably big enough sections of code and so isolated that you would probably only be working on one at a time.

I mean this sort of file structure:

Code: [Select]
Modules\
    DNA\
        Trunk\
        Branches\
        Tags\
    Physics\
        Trunk\
        Branches\
        Tags\

vs.
Trunk\
    Modules\
          DNA\
          Physics\
Branches\
  Tags\

It should be set up so that if the code is at version 3.42, I can go back and build version 3.26.  It doesn't necessarily have to be easy, but it should be possible.  But if branching and tagging works on the level of modules, we can't easily tag version global version 3.26, since version 3.26 might involve different versions of a dozen different modules.  Also, it means that coders have to maintain a dozen different SVN projects.  Making sure you're synced to trunk on every module would be extremely tedious.

Quote
* hot swappable implies to me that it can be done while the application is up and running, which of course we can do easily enough via a drop down menu etc. Just unload one assembly and load in the new one. But is that what you meant?

Yes, that was my thinking.  Maybe run two DNA assemblies at the same time.  Have on species use regular DNA, and another use a custom neural net module.

Quote from: Cyberduke
In fact maybe the solution files shouldn’t go in the SVN altogether, since that would allow me to use VS2008 and just put whatever collection of modules in my solution I wanted. And if someone wanted to use a different IDE they could, Framework 2.0 code is still Framework 2.0 code

Ah this will screw up Nunit... bad idea abort abort..

Right now the NUnit tests are run as a post build event.  It should be IDE independent, other than setting up the post build event (or running from the NUnit GUI or whatever).  Do you need different project files between 2008 and 2005?  That'd be a pain.

Offline Cyberduke

  • Bot Builder
  • **
  • Posts: 88
    • View Profile
DB3 Versioning
« Reply #7 on: October 01, 2008, 05:23:10 PM »
Quote from: Numsgil
Quote from: Cyberduke
Yes...
If the modules (assemblies) are going to be totally independent then they should probably have their own SVN trunk and branch structures, they can still come together in the same VS Solution. I think that’s what you meant

Edit:- You would want to build a solution file for each release version though. Other than that they are probably big enough sections of code and so isolated that you would probably only be working on one at a time.

I mean this sort of file structure:

Code: [Select]
Modules\
    DNA\
        Trunk\
        Branches\
        Tags\
    Physics\
        Trunk\
        Branches\
        Tags\

vs.
Trunk\
    Modules\
          DNA\
          Physics\
Branches\
  Tags\
Yeah that’s what I was trying to describe

Quote from: Numsgil
It should be set up so that if the code is at version 3.42, I can go back and build version 3.26.  It doesn't necessarily have to be easy, but it should be possible.  But if branching and tagging works on the level of modules, we can't easily tag version global version 3.26, since version 3.26 might involve different versions of a dozen different modules.  Also, it means that coders have to maintain a dozen different SVN projects.  Making sure you're synced to trunk on every module would be extremely tedious.
Thats starting to sound complicated...

Quote from: Numsgil
Quote from: Cyberduke
* hot swappable implies to me that it can be done while the application is up and running, which of course we can do easily enough via a drop down menu etc. Just unload one assembly and load in the new one. But is that what you meant?

Yes, that was my thinking.  Maybe run two DNA assemblies at the same time.  Have on species use regular DNA, and another use a custom neural net module.
Yeah, just load up all the assemblies in a "module" folder then run though them all looking for the DNA class type, make an instance of each one it finds and then add it to a dictionary, then you just need to look up which instance to use when.

Quote from: Numsgil
Quote from: Cyberduke
In fact maybe the solution files shouldn’t go in the SVN altogether, since that would allow me to use VS2008 and just put whatever collection of modules in my solution I wanted. And if someone wanted to use a different IDE they could, Framework 2.0 code is still Framework 2.0 code

Ah this will screw up Nunit... bad idea abort abort..

Right now the NUnit tests are run as a post build event.  It should be IDE independent, other than setting up the post build event (or running from the NUnit GUI or whatever).  Do you need different project files between 2008 and 2005?  That'd be a pain.
Yes, well we can play about with that at another time, it’s not really important for now I suppose. There are all kinds of options for automatically building all the project and solution files, with this exact scenario in mind (Multiple IDE’s).
 XNA 2.0 only works on VS2005 and XNA 3.0 will allow it to work on VS2008 but I haven’t looked into what the difference actually is. I have both VS2005 and VS2008 anyway. So forget this for now and we'll use VS2005 for simplicity
« Last Edit: October 01, 2008, 05:38:42 PM by Cyberduke »

Offline Numsgil

  • Administrator
  • Bot God
  • *****
  • Posts: 7742
    • View Profile
DB3 Versioning
« Reply #8 on: October 01, 2008, 05:43:43 PM »
Quote from: Cyberduke
Quote from: Numsgil
It should be set up so that if the code is at version 3.42, I can go back and build version 3.26.  It doesn't necessarily have to be easy, but it should be possible.  But if branching and tagging works on the level of modules, we can't easily tag version global version 3.26, since version 3.26 might involve different versions of a dozen different modules.  Also, it means that coders have to maintain a dozen different SVN projects.  Making sure you're synced to trunk on every module would be extremely tedious.
Thats starting to sound complicated...

Yes, I'm going to have to play with it this weekend.  Maybe I can set up some batch files to handle the complexity, and just require people to install a command line version of SVN or something.  I like the idea of tagging and branching individual modules, since it allows different paces for development for different systems.  But there are practical issues that need to be addressed.