• Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Groups
  • Search
  • Register
  • Login
UBports Robot Logo UBports Forum
  • Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Groups
  • Search
  • Register
  • Login

semantic versioning for UT

Scheduled Pinned Locked Moved OS
7 Posts 6 Posters 1.9k Views 3 Watching
Loading More Posts
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • M Offline
      mariogrip Administrators
      last edited by mariogrip 16 Oct 2018, 22:02

      With the new idea for changing up OTA process, I also want to propose new version system that makes sense.

      I propose to use Semantic Versioning
      https://semver.org/

      0_1539724648267_c4f00cf3-507c-4db6-bbb8-be949563f74f-image.png

      This way we could completely get rid of framework and only rely on the version to describe both version and api/abi compat. It would also give you a lot more info about the version you are on example that a major bump has a much bigger change then for example patch.

      MAJOR: bigger change that Breaks ABI/API
      MINOR: adds backwards-compatible bug fixes, changes and functionality (may break smaller library ABI in really special cases, but this should be notified about!)
      PATCH: adds backwards-compatible bug fixes.

      Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format.

      This would be how our different channels would look
      1.6.2-beta2 -> 1.6.2-rc1 -> 1.6.2
      beta -> rc -> stable

      This way you would know what version becomes what, example you know that 1.6.2-rc will become 1.6.2 stable.

      This fits great in with the "gotta go fast" proposal by dalton, here is an example how that would work

      1 week:

      • 1.5.6-devel0
      • 1.5.6-devel1
      • ----- / ----- Devel continues like this daily
      • Last weeks rc becomes stable: 1.5.5-rc1 -> 1.5.5
      • Last devel build of the week becomes rc: 1.5.6-devel6 -> 1.5.6-rc1

      2 week:

      • New devel version starts: 1.5.7-devel1
      • Last weeks rc becomes stable: 1.5.6-rc1 -> 1.5.6
      • Last devel build of the week becomes rc: 1.5.7-devel6 -> 1.5.7-rc1
      • This continues weekly.

      Then monthly we do a minor bump with more advances feathers.

      We could also do a mix between slow and fast, where we are releasing stable monthly:
      1 week:

      • 1.5.6-devel0
      • 1.5.6-devel1
      • ----- / ----- Devel continues like this daily
      • Last devel build of the week becomes rc: 1.5.6-devel6 -> 1.5.6-rc1

      2 week:

      • Devel continues daily
      • Last devel build of the week becomes rc: 1.5.6-devel12 -> 1.5.6-rc2
      • This continues weekly

      Then after the month is over last weeks rc becomes stable: 1.5.6-rc1 -> 1.5.6

      Examples:

      xenial stable: 1.6.2
      xenial rc: 1.6.2-rc0
      xenial rc: 1.6.2-rc1
      xenial devel: 1.6.2-devel1
      bionic devel: 2.6.2-devel1

      We would also make a clear build date in settings, this way we can know we are on the latest build.

      D 1 Reply Last reply 17 Oct 2018, 05:06 Reply Quote 2
      • D Offline
        dobey
        last edited by 17 Oct 2018, 01:24

        But this is not really any different from a framework version. The real problem isn't whether or not the version referenced is ubuntu-sdk-X or just X as is proposed, but whether what's on the image will satisfy that ABI or not No "semantic versioning" proposal will solve that issue really, because we don't provide the ABI/API as something for which multiple versions can be installed.

        1 Reply Last reply Reply Quote 0
        • D Offline
          doniks @mariogrip
          last edited by doniks 17 Oct 2018, 05:06

          @mariogrip content wise I dont have a strong opinion pro/contra, just some minor nitpicking:

          most of the time you start counting at devel0, except in gotta go fast, week 2. please make it consistent.

          i think your final example would be morr logical if it were

          bionic: 2.3.7-devel1 because minor and patch will not be equal with xenial in general, but the label at the end will.

          it would help to link the gottagofast thread

          1 Reply Last reply Reply Quote 0
          • A Away
            alan_g
            last edited by 17 Oct 2018, 08:48

            @mariogrip said in semantic versioning for UT:

            Last weeks rc becomes stable: 1.5.5-rc1 -> 1.5.6

            I think this is confusing. I prefer the Debian scheme where 1.5.6~rc1 -> 1.5.6

            R M 2 Replies Last reply 17 Oct 2018, 12:20 Reply Quote 1
            • R Offline
              rogier.oudshoorn @alan_g
              last edited by 17 Oct 2018, 12:20

              @alan_g Same here; maven versioning which i'm used to also goes from 1.5.6-SNAPSHOT -> 1.5.6 (release).

              1 Reply Last reply Reply Quote 0
              • M Offline
                mariogrip Administrators @alan_g
                last edited by 17 Oct 2018, 15:20

                @alan_g Yes that what i meant, sorry a mistake.

                1 Reply Last reply Reply Quote 0
                • L Offline
                  L-00581
                  last edited by 29 Jun 2021, 16:53

                  This post is deleted!
                  1 Reply Last reply Reply Quote 0
                  • L Lakotaubp locked this topic on 29 Jun 2021, 18:29
                  • First post
                    Last post