New release / Version numbering

Why OSVVM™? › Forums › OSVVM › New release / Version numbering

Viewing 4 posts - 1 through 4 (of 4 total)
  • Author
    Posts
  • June 28, 2012 at 00:17 #392
    Matthias Alles
    Member

    Hi guys,

    thank you for the new release. However, I’m a bit confused. You mentioned that you released version 2.3.1 of OSVVM. Within the ZIP the CoveragePkg uses version 2.3. Furthermore I couldn’t find any release notes that state what has changed within the package (are the minor modifications of the package invisible to the user?). That would be really appreciated from my side.

    Maybe it makes sense to use the same version number for all packages/source files contained? So Version number 2.3.1 could be the version for the RandomPkg as well? In this way, the packages would always be consistent and it would be clear to the user that he always has to use packages of the same version for usage of OS-VVM.

    Another approach for version numbering could be to use <yyyy>.<mm> (e.g., 2012.06), which is very common these days. I think it is beneficial to use this scheme from a marketing point of view.

    Best regards,
    Matthias

    June 28, 2012 at 15:25 #393
    Jim Lewis
    Member

    Hi all,

    The current OSVVM release numbering vs file revision numbering is my fault.  Part of it is because I come from a background of using file based revision systems (like RCS or SVN) as opposed to project based revision systems (like git and hg).     

    Does anyone have suggestions for organizing an open source repository for a collection of packages?   Do we keep it in one big git/hg repository or do we use submodule repositories for each set of packages?

    A readme file is probably a good idea for the release.  OTOH, with a revision control system like git or hg, how do we track revisions to a particular file.  Wandering through the readme log may be quite tedious.  We might be able to do some of this with twiki files in the respository.

    Any comments about the available hosting based on your

    experience with them is appreciated. 

    If you would rather send a personal response my email is jim at synthworks dot com

    Best,

    Jim

    April 27, 2013 at 17:30 #548
    Jim Lewis
    Member

    Hi Matthias,

    I think you are referring to release numbering rather than version numbering.  For the next release, I numbered all the files and documentation 2013.04.

    If we add to the library, this probably will not be practical to keep doing – does git have any form of version tags that allow you to have the release numbering added in the files?  RCS and SCCS had this, have not seen any of this in the git documentation (I am fairly new to using git).

    Jim

    April 29, 2013 at 00:38 #549
    Matthias Alles
    Member

    Hi Jim,

    Yes, I was referring to the release numbering. git doesn’t even know revision control version numbers anymore, as Linus Torvalds considers them not to give any additional information. All that counts for him is whether a patch is included in the repository or not. It is possible to tag a certain status of the repository with git, e.g. the release candidate or the release.

    I don’t think one wants to have version numbers of the revision control system in the files. There’s no need for this. For the release version, I guess one has to bump it by hand, but it’s not a big deal as this should happen only for the release. 

    Matthias

  • Author
    Posts
Viewing 4 posts - 1 through 4 (of 4 total)
  • You must be logged in to reply to this topic.