Code center > Darwinbots3

DB3 Versioning

(1/2) > >>

Cyberduke:
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.

Numsgil:
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...

Cyberduke:
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.

Numsgil:
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.

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.

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?

Navigation

[0] Message Index

[#] Next page