ROMS new version

Message

m.hadfield · Thu Apr 19, 2007 3:09 am

This is a response to Hernan's message about the new ROMS version on the "ROMS Releases" forum (which I don't have permission to post to):

viewtopic.php?t=495

I thnk management & distribution of the ROMS source with SVN is a good thing. However I would like the process of creating & identifying ROMS releases to be a little more formal than it is at present. I suggest that ROMS use a structure that is widely used elsewhere, eg Mozilla Firefox, Windows

.

The idea is that the development tree has a trunk containing a recent, but not stable, version of ROMS. Developers like Hernan check out the latest version from the trunk, add new features and check them back in. This is what happens at the moment, I think. The more adenturous ROMS users will keep their copies of the code up to date with this version.

The other part of the scheme is that from time to time (every year perhaps) a release is planned when several new features are reasonably well tested. At an appropriate point (eg, about now) a branch is forked off the trunk. this branch becomes a release version and is subject only to bug fixes (most of which will also be copied back into the trunk). The branch will be preserved indefinitely so that users can rely on a stable, reference version, but with the more sever bugs fixed.. Meanwhile the excitement-loving developers go back to work developing the trunk.

I understand SVN supports this sort of structure, better than CVS because SVN allows tree-wide revisions to be identified.

Is this what you are planning, Hernan?

kate · #2 Unread post by **kate** » Thu Apr 19, 2007 4:53 pm

Here, here! I agree with Mark - make the "official versions" tagged releases and make sure they get bug fixes applied.

What Hernan has now is separate repositories for the "official versions" and the development code, so an "svn switch" between them doesn't currently work. This is to keep the private code private, with a different access list.

By the way, I have a powerpoint file on how I've been managing svn in the face of a read-only repository here. Comments welcome.

arango · #3 Unread post by **arango** » Fri Apr 20, 2007 2:52 am

Well, let me think about this. Obviously, we cannot do nothing to previous released versions. The current structure of the official ROMS repository is:

https://www.myroms.org/svn/src

* branches
* tags
- * roms-2.0
  * roms-2.1
  * roms-2.2
  * roms-2.3
* trunk

Currently, we don't have any branches and we don't know it will have any in the future. There are already several tagged versions. The version 2.3 was tagged last February before we started a massive update of the code structure. The next release will be tagged as version 3.0 next week when we finish all the refining and testing. At this point, the trunk will have exactly the same version.

It is possible to do what Mark is suggesting and Kate is supporting, but lets think about this first before we make any decision. Mark is proposing to keep updating tagged version to correct for bugs only. Then, the trunk will contain corrected bug plus new developments. So the question is, how many tagged versions do we need to be updating in the future? 3.0, 3.1, ..., and so on. Or we need to update the previous version only. Well, this is kind of problematic and it is not clear to me what will be the best way to proceed.

The problem here is that sometimes, in addition to correcting bugs, we do some improvements that actually are not considered as new developments. This is a gray area with not well defined boundaries.

Noticed that all the developers have their own branch in different repositories which are restricted and not available to everybody. The official repository will be open to everybody next week.

hetland · #4 Unread post by **hetland** » Sat Apr 21, 2007 3:09 am

There is not much to think about, as the release of tagged versions is done often for many open source software projects. This is how it goes:

Official release versions (in the future, of course) are nothing more than snapshots of the svn repository. These are usually tagged in the svn repository with the version number. They should be relatively bug free (developers should make no new changes before a release), and there should be a period before the release where people look for bugs. These official release versions can be made available as tarred (and zipped) files on the home page for people who do not wish to deal with svn and potential bugs introduced by new features.

wilkin · #5 Unread post by **wilkin** » Sun Apr 22, 2007 4:07 pm

hetland wrote:
Official release versions (in the future, of course) are nothing more than snapshots of the svn repository. These are usually tagged in the svn repository with the version number. They should be relatively bug free ... These official release versions can be made available as tarred (and zipped) files on the home page for people who do not wish to deal with svn and potential bugs introduced by new features.

Hernan and I discussed this at some length on Friday but didn't come to a clear conclusion. Rob's suggestion above seems to advocate for not applying any changes to tagged versions, which is my preference. It is a clear and unambiguous policy, with no grey areas, and conserves developer time to focus effort on new features and fixing newly identified bugs.

Inevitably there will be some future bug that relates to a feature not in a previous version, or that conflicts with previous features (or even bug fixes). As Hernan said earlier, if we apply bugs to previous tagged versions where does it stop? If the current release is, say, 3.9, why would we fix 3.0, 3.1, 3.2.... and who would we be expending all that effort for? We would also have to identifiy the bug fixed branches as 3.1.1, 3.1.2 etc because otherwise the users can't know whether some one reporting a problem to the forum is encountering a known bug.

I don't think comparisons to version control for projects like Mozilla or Windows are really all that useful here. Like most of you, I use Windows, Thnderbird and Firefox and apply all updates regularly. I seldom read the release notes. I can't conceive of a problem that would send me back to install a previous version, unless it was something that would probably actually be better solved by upgrading somethig else (like a plugin).

With ROMS, most users can operate the same way because they do all the I/O through the netcdf files and the I/O config has been quite stable recently. For those who make small changes to configurations through analytical options these are relatively easy to keep current. Similarly, for users making changes within application codes like biology.F, these are relatively self-contained.

If as a user you find it tiresome to keep your local code in step with releases then you should contribute a stable version back to the group like a good ROMS citizen and continue your development privately.

If the vast majority of users keep current with svn that let's save our energy and leave the tagged versions alone, and then we can also allow the user forum to share the work of alerting users encountering known bugs.

John.

m.hadfield · Mon Apr 23, 2007 1:49 am

John wrote

I don't think comparisons to version control for projects like Mozilla or Windows are really all that useful here.

You're right, Python is the best model for what I'm thinking of. See the list of versions available at the download page:

http://www.python.org/download/

The current production version is 2.5.1, which is a bug-fix update of 2.5. Then there are 2.4.3, which is a bug-fix update of 2.4, and 2.3.6, which is a bug-fix update of 2.3. The 2.5, 2.4 & 2.3 branches are still being maintained, as evident in the fact that new bug-fix versions have been released in the last year. The 2.2, 2.1, 2.0 and older branches haven't had a new version for a few years now.

Whenever a new release is made (i.e. an increment in the first or second version number) a maintainer is appointed to be responsible for the corresponding branch and given instructions to apply only bug fixes. (The maintainer should be someone with a high boredom threshold.) The bug-fixes-only rule is applied quite strictly to avoid having the updates break code that relies on a particular version.

If all this is too much trouble, that's fine. I just thought it would be good to discuss this stuff.

arango · #7 Unread post by **arango** » Mon Apr 23, 2007 3:57 am

Yes, we are fully aware that there has not been new releases of ROMS for the last two years. ROMS is still very alive and evolving. There have been few bug corrections to version 2.2 but nothing catastrophic. We have being buying time since the new developments are quite complex and we wanted to be sure that the next release is very stable.

The new version includes all the adjoint developments and we needed to freeze any change to the kernel until we were quite sure that we had the correct tangent linear and adjoint model algorithms. Any single line change to the kernel will affect the adjoint. In view of this, we needed to redesign a little the structure of ROMS and remove all the reasons for the users to modify any of the internal codes. I think that we achieved this in the new version.

It took John Warner and I nearly two months to review all the changes related with the sediment model and its associated new features. We have been very busy. We hope that with the new svn version control it will be easier for developers and users to update and correct the ROMS algorithms. I am pretty sure that the trunk will be updated more frequently from now on. We also will tag new versions when appropriate.

We are providing the capability to the user to reproduce any result since enough information about the revision control is now included in the output NetCDF files. We just ask you that from now on, to include the repository revision that you are using when reporting problems in this forum.

Now, the official ROMS repository is only available for reading. We cannot have branches for all the hundreds of users out there. We recommend the user to keep a clean copy of ROMS official repository in their computers. Then, the user can have their own private repository or make copy of the trunk for their own work. We will include more information and recommendations on wikiROMS.

By the way, John and I will take few days off after the release