Difference between revisions of "User:Osai/Repository"
From #openttdcoop wiki
(mock-up subversion, versioning and grfpack) |
(No difference)
|
Latest revision as of 22:26, 14 February 2008
This is a mock-up of the concept for the openttdcoop svn repository.
Contents
Suggestion
- grfpack
- branches [maybe not necessary]
- tags [grfpack releases]
- trunk [development mainline]
- osqc
- trunk [development mainline]
- scripts [includes sub-projects without an own structure (trunk/tags/branches), they are tiny and we don't need it]
- ottd-config-tool
- admin-routines
Possibilities
- wwottdgd [wwottdgd related stuff maybe?]
- ...
- trunk
- etc...
- ...
- coopetition
- trunk
- tags
grfpack versioning
Nomenclature Type 1
Another important topic is the versioning and administration of our grfpack with svn. Subversion is a really nice tool having a big disadvantage: common users don't even know it. We have to provide packages (zip, tar, etc.) to download to maximise the accessibility. This means, we can NOT update every time we change the trunk the packages as well. In my opinion we should release new versions every 3 months. Its a period being not too long, but long enough to have a certain amount of updated grfs and/or new grfs which are worth and update. < I'm sorry for this long sentence. In case of ugly bugs and dirty issues we can 'do' an emergency release.
- Base: ottdc_grfpack
- Year: 08 [changes yearly]
- Quarter: 1-4 [changes quarterly]
- Sub-/Emergency Release: .1 [changes if an urgent update is needed]
Example: ottdc_grfpack-08-1.1
Nomenclature Type 2
Another variant quite similar to our current scheme. Base: ottdc_grfpack
- Version: 6 [Could change after major changes]
- Sub-/Plus-/Emergency Release: .1, +1
Example: ottdc_grfpack-6.1
Example: ottdc_grfpack-6.13
Example: ottdc_grfpack-6+1
Automatism
Of course I tend to create some scripts which create the packages automatically. Quarterly releases could be executed via crontab and another script could be used to create sub-releases. Of course a package will only be released if it changed.
Some more things in my mind: Updating grfs via DB, which generates the necessary code for Wiki:GRF_Table