Loading ...
Sorry, an error occurred while loading the content.

Version marking

Expand Messages
  • nwaston2003
    Currently: PR = pre-release and identifies the software as non-Production software. We adjust the internal version string and put a version mark on the
    Message 1 of 6 , May 29, 2003
    • 0 Attachment
      Currently:
      "PR" = pre-release and identifies the software as non-Production
      software.
      We adjust the internal version string and put a version mark on the
      source files as e.g. "1.2.3.4 PR" and then get the sources and do a
      full build. An automatic test is performed and then an independent
      evaluation test. After a few cycles the software is found to be
      clean.
      We then adjust the internal version string and version mark as
      e.g. "1.2.3.4" without the "PR" suffix. A quick confidence check is
      performed.

      However, our indepdnent evaluators argue that they should do a full
      check on the software since everything has been rebuilt.

      Can anyone suggest a better scheme where we can use cleaner "PR" and
      non-PR labelling without doing a full rebuild and therefore
      upsetting the independent evaluators?

      Nigel
    • Robert Blum
      Two things come to mind. One is the matter of acceptance tests. If it passes all your acceptance tests, your evaluators should be satisfied, or suggest new
      Message 2 of 6 , May 29, 2003
      • 0 Attachment
        Two things come to mind. One is the matter of acceptance tests. If it
        passes all your acceptance tests, your evaluators should be satisfied,
        or suggest new tests. What are they testing that is not covered by
        acceptance tests? And why is it not covered?

        In case relying on ATs alone is not possible, I suggest doing the
        simplest thing that could possibly work - move the version number into
        a text file. Easily changed, no rebuild required. Or have a file that
        by its existence marks your version as "PR".

        - Robert
      • George Dinwiddie
        You don t say what sort of build you re doing. If java, you can put your version information into one of the files in the jar; then just update that one file.
        Message 3 of 6 , May 29, 2003
        • 0 Attachment
          You don't say what sort of build you're doing. If java, you can put
          your version information into one of the files in the jar; then just
          update that one file. If c++, you could find the version string in the
          executable and overwrite the "PR" with a couple of nul characters.

          nwaston2003 wrote:
          > Currently:
          > "PR" = pre-release and identifies the software as non-Production
          > software.
          > We adjust the internal version string and put a version mark on the
          > source files as e.g. "1.2.3.4 PR" and then get the sources and do a
          > full build. An automatic test is performed and then an independent
          > evaluation test. After a few cycles the software is found to be
          > clean.
          > We then adjust the internal version string and version mark as
          > e.g. "1.2.3.4" without the "PR" suffix. A quick confidence check is
          > performed.
          >
          > However, our indepdnent evaluators argue that they should do a full
          > check on the software since everything has been rebuilt.
          >
          > Can anyone suggest a better scheme where we can use cleaner "PR" and
          > non-PR labelling without doing a full rebuild and therefore
          > upsetting the independent evaluators?
          >
          > Nigel
          >
          >
          > To Post a message, send it to: extremeprogramming@...
          >
          > To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe@...
          >
          > ad-free courtesy of objectmentor.com
          >
          > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
          >
          >
          >

          --
          -------------------------
          George Dinwiddie
          agile programmer for hire
          Baltimore/Washington area
          gdinwiddie@...
          -------------------------
        • William Pietri
          ... Perhaps the problem is the overloading of the version numbers to have two kinds of meaning. Consider adding a build number to the identifier, so that if
          Message 4 of 6 , May 29, 2003
          • 0 Attachment
            On Thu, 2003-05-29 at 04:00, nwaston2003 wrote:
            > Can anyone suggest a better scheme where we can use cleaner "PR" and
            > non-PR labelling without doing a full rebuild and therefore
            > upsetting the independent evaluators?

            Perhaps the problem is the overloading of the version numbers to have
            two kinds of meaning.

            Consider adding a build number to the identifier, so that if you are on
            project version 1.2.3, you might make the version string "1.2.3.20", or
            "1.2.3 build 20". This makes the version string carry no extra weight.

            Eventually, some build will be nominated as a release candidate. If it
            passes the full cycle, it will be the thing that gets released.
            Internally, y'all will know that it's the golden build, but your
            customers will mainly think of it as version 1.2, or version 1.2.3.

            William

            --
            brains for sale: http://scissor.com/
          • nwaston2003
            Thanks Your suggestion is ok. It does not help with being able to label a release as PR so that if it gets outside of the company then we will easily know
            Message 5 of 6 , Jun 1, 2003
            • 0 Attachment
              Thanks
              Your suggestion is ok. It does not help with being able to label a
              release as "PR" so that if it gets outside of the company then we
              will easily know it is pre-release.
              We are using Visual Studio and C#, and building into an msi
              installer. Ideally we do not want to even build the msi installer
              again.
              Nigel

              --- In extremeprogramming@yahoogroups.com, Robert Blum <r.blum@g...>
              wrote:
              > Two things come to mind. One is the matter of acceptance tests. If
              it
              > passes all your acceptance tests, your evaluators should be
              satisfied,
              > or suggest new tests. What are they testing that is not covered by
              > acceptance tests? And why is it not covered?
              >
              > In case relying on ATs alone is not possible, I suggest doing the
              > simplest thing that could possibly work - move the version number
              into
              > a text file. Easily changed, no rebuild required. Or have a file
              that
              > by its existence marks your version as "PR".
              >
              > - Robert
            • William Pietri
              ... I m afraid Windows stuff is so much greek to me, but it sounds like you should make the PR marker something external to the build, as your process treats
              Message 6 of 6 , Jun 2, 2003
              • 0 Attachment
                On Sun, 2003-06-01 at 23:29, nwaston2003 wrote:
                > Thanks
                > Your suggestion is ok. It does not help with being able to label a
                > release as "PR" so that if it gets outside of the company then we
                > will easily know it is pre-release.
                > We are using Visual Studio and C#, and building into an msi
                > installer. Ideally we do not want to even build the msi installer
                > again.

                I'm afraid Windows stuff is so much greek to me, but it sounds like you
                should make the "PR" marker something external to the build, as your
                process treats it that way. For example, the "about" box could check
                over the internet to find out whether build 1234 is a PR or a golden
                build and change its look accordingly.

                Or the "PR" part could be kept in the installer's configuration file, so
                that different artwork would be installed depending on whether it was PR
                or golden. Then the QA team can test both modes of operation. The
                default mode would be "PR", of course, but the last step in the release
                process would be to change that one bit in the configuration file.

                William


                --
                brains for sale: http://scissor.com/
              Your message has been successfully submitted and would be delivered to recipients shortly.