[tssg-tech] Fwd: TSSG project item
- From: Lucy Hamnett <lucy@xxxxxxxxxxxx>
- To: tssg-tech@xxxxxxxxxxxxx
- Date: Wed, 9 Nov 2011 10:34:13 -0500
Hi Folks,
I know I didn't send out an agenda this week, but we are meeting as usual
at 1:30 in Acton Memorial Library.
Attached is email from Jim Peters in response to a request to be put on the
agenda. He landed a job! (so he cannot be on the agenda). Still he kindly
shared his thoughts on using SVN for splitting off a Beta before we
continue on other work. Good Luck Jim and thanks :)
See you this afternoon
Lucy
---------- Forwarded message ----------
From: Jim Peters <jpeters@xxxxxxxxxxx>
Date: Mon, Nov 7, 2011 at 9:20 PM
Subject: Re: TSSG project item
To: lucy@xxxxxxxxxxxx
I saw a message from Andy just about when I was going to pack up and go, so
it turned out to be a non-issue for me.
At around 2:00 on Friday, I learned I have come down with something the
doctor tells me is known as a "job". I started today. So obviously I
won't be making meetings on a regular basis. I would have made last week
with a real computer and monitor. That's what I get for making such an
investment. ( I bought myself a 22 inch monitor and was planning to
bring my mac mini.) So that's my prescription for all of you.
I am working for Dovetail Internet Technologies in Worcester. I ended up
in a different role than what I was describing the last time I made a
meeting. Its an even better fit for my skills so I can meet their needs
even more immediately. And they are wasting no time in letting me know.
;-)
The paragraph or two answer that occurs to me is that I think it is common
in the industry for companies or open source projects using subversion to
incorporate the number of a subversion changeset into their version number
for a specfic release. Subversion changest numbers are global and unique
throughout the repository. This in unlike Clearcase where a version
number you see with a file or directory in clearcase is incremented at the
branch level.
My experience suggests that if I were at a company producing this and
trying to lay the groundwork for what development does and hands off to QA
for Alpha, Beta and "Gamma" or C releases in preparation for FCS (First
Customer Ship) and GA (Generally Available) I'd recommend adopting a four
digit naming scheme where the four numbers stand for
major.minor.maintenance.patch. The major and minor releases were for
those phases up to FCS and primarily used in development. When FCS and GA
were done, the world had copies of our code so those numbers had to last
and be cast in stone for legacy. The system I saw that worked well was
to use the letters A, B, C for the Alpha through Gamma releases. In the
cycle of things, a final C release became a V release to GA. The only
difference between C and V was the labeling of it. After that patches and
maintenance releases were done as P to provide a quick fix. When the
collection of P's since a maintenance release were brought together as the
next maintenance, it was shipped as V2.0.1.0. Customers understood that
V stood for version, P for Patch.
There is more to how to increment the numbers, that I'll skip explaining.
I think for the project that if you release something it should be 1.0
followed by 1.1 or 1.2 for small incremental changes. I'd also figure out
if I'm right about changeset numbers being global and commonly used and
then add them to the version number such as 1.1.101 when you do a build.
Then if you had a build at About and gave you a version number it would
tell you that this is 1.1 up to change set 101. Using a timestamp to set
your place in source control is a bad idea because not everybody's clock is
the same.
Again I'm trying to compress a whole discussion into a few paragraphs.
Please feel free to include me in this if you think it would help. I'd
like to stay on some list so I know what's going on in the skills group but
obviously my time is going to be first devoted to the new job -- which does
use subversion as is at the company and for the products that I worked on
three years ago so there is some value there, but I won't be looking at
their details too soon. I am not in a QA or software engineering role.
I'm doing more of a customer service and internet networking role for all
things having to do with hosting (domain names, certificates, ip addresses
and that bucket of things.)
Jim.
On Nov 6, 2011, at 4:27 PM, Lucy Hamnett wrote:
> Hi Jim,
>
> I'm sorry about last week; apparently gmail on my iphone let me send the
cancellation email into oblivion without letting me know. (sigh)
>
> Anyway, from the previous week, when we didn't have a huge number of
people participating, one of the suggestions we wanted to put on the agenda
was to discuss the endgame of phase1 moving to phase 2 with respect to our
source repository. As a release engineer we thought that you might be able
to plan this for us, so that we know what to do with respect to SVN,
especially as most of us are not too familiar with making decisions about
release protocols etc.
>
> Essentially, we need to be able to save/archive the existing code (or at
least the code when we think we're done with Phase 1) and be able to build
it, test it, and maybe make changes to it, while we proceed with other
items people want to pursue.
>
> This coming week, I plan to go over the requirements document, suggesting
which items in the delayed list (and any new ones that come up) might be
worked on to produce something better than our phase1 product.
>
> If you have any insights you can share, or wish to write up your
suggestions of what to do, it would be very appreciated. Maybe have you
present the following meeting if anything needs explaining, or just to show
and tell. (I know you might be subbing, so I'm not going to write you on
the agenda in stone :)
>
> Let me know what you think.
>
> Cheers
>
> Lucy
Other related posts:
