What is your versioning strategy?

Hi All,

I'm currently working on some code that interprets VersionString as a set of Branches and Versions. I'd like to know what versionString format you use to determine branching in your projects. At Cincom we do the following:

Branch - Version + Branch Version + Branch Version + Branch Version ....
eg: 7.9 - 4 + AR 58932 3

Please post your examples.

Cheers,
Michael
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Michael,

We do whole numbers for 'head' and various numbers of periods for
branches, so,

1
1.1
1.2 (first branch of 1)
1..1
1..2 (second branch of 1)
1...1
1...2 (third branch of 1)

It looks a bit odd at first, but works very well for our small team.

Regards,

-Boris

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On
Behalf Of Michael Lucas-Smith
Sent: 05 May 2011 18:01
To: VW NC; VWDEV List
Subject: What is your versioning strategy?


Hi All,

I'm currently working on some code that interprets VersionString as a
set of Branches and Versions. I'd like to know what versionString format
you use to determine branching in your projects. At Cincom we do the
following:

Branch - Version + Branch Version + Branch Version + Branch Version ....
eg: 7.9 - 4 + AR 58932 3

Please post your examples.

Cheers,
Michael

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

We use whole numbers for the trunk.  Anything else is a branch (we try to be consistent for subsequent versions of the same branch, but there is no consistency from one branch to another).  We actually try to avoid branches as much as possible, but for some experimental stuff we might publish on a branch.
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

We use:

VW Version - trunk.branch.branch...

So:

7.6 - BPR 18.4

For a branch:

7.6 - BPR 18.4.1

And so on


On May 5, 2011, at 6:00 PM, Michael Lucas-Smith wrote:

James Robertson
http://www.jarober.com
[hidden email]




_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Dear Michael,

Interesting, because we have a few small but heavily used extensions
based on such a version string intepretation technique. (and also
package name intepretation, but that is an other story).

Maybe it helps if I also explain a little bit more about how we use
this "version string" interpretation at the moment.

1) Anything with an underscore is a branch, by which I mean a branch
that has to be merged back into trunk again. (not a  branch to
indicate a particual VW version, like 7.6, for that, see my point 4).
For the "merge-me-back-into-trunk branches" we've changed VW's
automatic versioning scheme to add underscores in stead of dots.  We
did this to have it more visually clear you have branched and have to
merge your work back into trunk, and also to make it more simple to
add tool support (only has to search for _ in version string).

e.g.

trunk is 11.0.55, if you branch (on purpose by setting the blessing
level to "work in progress" or incidentally), the automatic
versionnumber will become 11.0.55.1_1, and the next will be
11.0.55.1_2 etc.

2) More long-standing branches, which are most of the time also spread
out over several packages, are prefixed with an semantical identifier
e.g. "FeatureX  11.0.55.1_1". We added extra tool support to
"handle" these kind of branches.  e.g. we have store menu items like
"Unmerged branches", "Merge branch...", "Packages on branche...",
"Branched packages since...", "Packages on closed branch...", "Loaded
packages on branch...", "Possibly branched packages". (Menu-item-names
postfixed with the three dots indicate a dialog will follow where you
have to type in your branch name). We also added some functionality to
the "store publish dialog" so you can easily add these semantical
branch names to a set of packages at once

These "Working-branches" typically live for several days and keeps the
trunk more stable during these days.

3) Packages from others (cincom / the cincom repository) we prefix the
VW version and postfix with an initial version e.g. "7.6 x 1.0". (x is
the version number given by the other party, 1.0 is given by us). This
helps indicate if we or the other party changed a package.

4) For our own packages, a trunk version has three parts separated by
a dot, e.g 11.0.55, we've never used the middle part, so that can be
skipped, the last part is raised every publish, the first part is only
raised when an "important technical infrastructure part" is changed
like a new VW version, DB version, a particular important package
version etc.

All this "version string" interpretation doesn't feel very object
oriented, but this was the easiest way for us to extent store with
better branch support. (Becoming more and more important with the
growth of our development team, amount of code, deployment frequency
etc. ).

Hope this helps you & greetings,

Mathieu van Echtelt

ps. close related to this issue: "package name string" interpretation.
This is used to support concepts like configurations and lineups, also
not very object oriented, but still, much much better for our
situation than what is offered by store out of the box. see
http://www.cincomsmalltalk.com/userblogs/travis/blogView?showComments=true&entry=3265388740

pps. Last year, we (ag5) discussed our "store usage" situation with
your collegues Alan Knight & Arden Thomas. An interesting but
difficult subject, especially because it looks like every development
team has his own habits and consequently, homebrew store extensions.

On Fri, May 6, 2011 at 12:00 AM, Michael Lucas-Smith
<[hidden email]> wrote:


--
Willem Fenengastraat 4C
1096 BN  Amsterdam
www.ag5.nl
Tel: 020-4630942
Fax: 020-4630946

----------------------------------------------------------------------------------
Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien
u niet de geadresseerde bent of dit bericht abusievelijk aan u is
toegezonden, wordt u verzocht dat aan de afzender te melden en het
bericht te verwijderen. Elk ongeoorloofd gebruik of verspreiding van
dit bericht, geheel of gedeeltelijk is strikt verboden.

This message may contain information that is not intended for you. If
you are not the addressee or if this message was sent to you by
mistake, you are requested to inform the sender and delete the
message. Any unauthorised use or dissemination of this message  in
whole or in part is strictly prohibited.

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

One of my clients uses a numbering scheme they brought forward from ENVY. They use the format:

   V3.02d

Where 3 is the major release number, 2 is the minor release number and d is the change number within the release. When they reach z they go into double characters aa, ab, etc.

They try to avoid branches by requiring developers to merge with the head version before publishing.

We developed a custom version naming policy to provide this numbering scheme.

David Buck

Sent from my BlackBerry device on the Rogers Wireless Network

-----Original Message-----
From: Michael Lucas-Smith <[hidden email]>
Sender: [hidden email]
Date: Thu, 5 May 2011 15:00:46
To: VW NC<[hidden email]>; VWDEV List<[hidden email]>
Subject: [vwnc] What is your versioning strategy?

Hi All,

I'm currently working on some code that interprets VersionString as a set of Branches and Versions. I'd like to know what versionString format you use to determine branching in your projects. At Cincom we do the following:

Branch - Version + Branch Version + Branch Version + Branch Version ....
eg: 7.9 - 4 + AR 58932 3

Please post your examples.

Cheers,
Michael
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Hi all,

 

In a previous post I read:

"Alterations to Cincom code are maintained as overrides in separate packages where the original Cincom package name is postfixed with the string ' patches', so these are branches too but the branch does not have a name as such and is to be found in(through?) the package names plane."

 

We do a similar thing with overrides, but I am looking for a tool to support and maintain those overrides.

My problem is when upgrading to a new version, I need to check every override manually and this is something I would like to automate.

 

If the override would know what the original code was, the override could compare itself when loaded over a new version of cincom if the new version is still the same as before.

If not, that override should be marked as to verify.

 

Any help is welcome

 

Mvg

Stefaan

 

 

 

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

We'll be upgrading from VW 7.6 to a newer rev at some point in the near term future as well.  While I don't have any tools, the following bit of script should help:
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Overrides do not inherently know what the previous version of the code is. If you publish something as a modified version of the containing package, then that would know what it was based on, but an unrelated package does not.  However, it would not be that difficult to record that information somewhere such that it could be used automatically. In fact, presumably most of the overrides in your situation would be of the versions distributed with the previous release. So simply collecting all of the overrides and comparing them with the appropriate code in the earlier release would do it. You know the name of the package, based on the name of your overriding package, so if you have a published version of the base of the old release and of the base of the new release (or you could just use the overridden code in the image for the new one) then that would be doable.

---

[hidden email]
May 19, 2011 8:23 AM

Hi all,

 

In a previous post I read:

"Alterations to Cincom code are maintained as overrides in separate packages where the original Cincom package name is postfixed with the string ' patches', so these are branches too but the branch does not have a name as such and is to be found in(through?) the package names plane."

 

We do a similar thing with overrides, but I am looking for a tool to support and maintain those overrides.

My problem is when upgrading to a new version, I need to check every override manually and this is something I would like to automate.

 

If the override would know what the original code was, the override could compare itself when loaded over a new version of cincom if the new version is still the same as before.

If not, that override should be marked as to verify.

 

Any help is welcome

 

Mvg

Stefaan

 

 

 

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

---

[hidden email]
May 5, 2011 6:00 PM

Hi All,

I'm currently working on some code that interprets VersionString as a set of Branches and Versions. I'd like to know what versionString format you use to determine branching in your projects. At Cincom we do the following:

Branch - Version + Branch Version + Branch Version + Branch Version ....
eg: 7.9 - 4 + AR 58932 3

Please post your examples.

Cheers,
Michael

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

---

This message may contain confidential information and is intended for specific recipients unless explicitly noted otherwise. If you have reason to believe you are not an intended recipient of this message, please delete it and notify the sender. This message may not represent the opinion of IntercontinentalExchange, Inc. (ICE), its subsidiaries or affiliates, and does not constitute a contract or guarantee. Unencrypted electronic mail is not secure and the recipient of this message is expected to provide safeguards from viruses and pursue alternate means of communication where privacy or a binding message is desired.

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Given that the typical case is that you're using a verision and upgrading, here's a code snippet if we're following the convention described. It finds all packages that follow that convention in the image, then finds the corresponding original package  in the image. Then it tries to find the original package from the old version. This assumes that you have it published in the current Store database, and that its name matches the string specified at the beginning. For most people that's probably relatively easy, as you won't have hundreds of versions named e.g. '7.7*'. In this case I did have to be careful to put a space after 7.7, because otherwise it would also match 7.7.1. But you can specify how to find the versions arbitrarily. Given that, we find the old overridden method in the Store package, and have the current source and the overridden version in the image. If the old and the new overridden source don't match it opens a text comparison view on the two of them. That could just as easily be writing them to Transcript or a file for later examination. It just requires that you have the version you originally overrode in the Store database, and a way to find it.

  If I were doing this on a project from scratch, I'd probably adopt the version naming convention for such patch packages that I version them with the name of the version I intended them to modify, so then it could easily and reliably be found programmatically.

mySession := StoreLoginFactory currentStoreSession.
versionToUpgradeFrom := '7.7 '.
patchPackages := Store.Registry allPackages select: [:each | each name like: '% patches'].
patchPackages do: [:eachPatchPackage |
    currentOverriddenPackage := Store.Registry packageNamed: (eachPatchPackage name readStream upTo: Character space).
    baseQuery := Query readOneOf: StorePackage where: [:each | (each name = (eachPatchPackage name readStream upTo: Character space)) & (each version like: '%', versionToUpgradeFrom, '%')].
    baseQuery orderBy: [:each | each timestamp descending].
    baseVersion := mySession execute: baseQuery.
    baseVersion inspect.
    eachPatchPackage methods do: [:eachMethodDescription |
        imageMethod := eachMethodDescription method.
        oldOverridden := baseVersion method: imageMethod selector forClassNamed: imageMethod mclass instanceBehavior absoluteName meta: imageMethod mclass isMeta.
        newOverridden := Override selector: imageMethod selector class: imageMethod mclass in: currentOverriddenPackage.
        (newOverridden isNil or: [oldOverridden sourceCode ~= newOverridden sourceCode]) ifTrue: [
            | view |
            view := SideBySideTextComparisonView new leftText: oldOverridden sourceCode rightText: newOverridden sourceCode.
            ScheduledWindow new component: view; openWithExtent: 800@600].
    ]].

---

[hidden email]
May 19, 2011 1:07 PM

What’s really needed is that when we publish an override, it remembers what the overridden method was (source code and where possible Store pointer). And when we load, it checks if the method it is overriding is the same as it was before.

 

Until we have that, we have to make do with hacks to reconstruct or guess this info on the fly. As Alan said, it should be possible for simple cases, e.g. if our method just overrides a base VW method, and Store contains all three versions: old Cincom, our override, new Cincom.

 

We need to find the timestamp when our override was published, then see if there’s a Cincom version published after that. If there is no “new Cincom” version, we’re fine.

 

I can get as far as a collection of all current method overrides by our packages to others’ packages:

 

overriddenColl := OrderedCollection new.

ourBundle := Store.Registry bundleNamed: 'OurMainBundle'.

ourPackages := OrderedCollection new.

otherPackages := OrderedCollection new.

Store.Registry allPackages do: [:pkg |

                ((ourBundle containsItem: pkg) ifTrue: [ourPackages] ifFalse: [otherPackages])

                                add: pkg].

otherPackages do: [:each |

                overriddenColl addAll: (Store.Registry pundleNamed: each name) overrides].

overriddenMethodsColl := overriddenColl select: [:overridden | overridden isForMethod].

overridenByUsColl := overriddenMethodsColl select: [:overridden |

                | overridingPackage |

                overridingPackage := Store.Registry containingPackageForSelector: overridden selector class: overridden correspondingImageClass.

                ourPackages includes: overridingPackage].

 

and later I can check the timestamps:

 

session read: StoreMethod where: [:eachMethod |

                (eachMethod name = overridden selector) AND: [(eachMethod className = overridden fullClassName) AND: [eachMethod timestamp > oldTimestamp]]]

 

but the bits in between and after are going to need more Store brains…

 

Steve

 

 

From: [hidden email] [[hidden email]] On Behalf Of Stefaan Denolf
Sent: 19. toukokuuta 2011 15:23
To: [hidden email]
Subject: [vwnc] What is your versioning strategy? - Overrides

 

Hi all,

 

In a previous post I read:

"Alterations to Cincom code are maintained as overrides in separate packages where the original Cincom package name is postfixed with the string ' patches', so these are branches too but the branch does not have a name as such and is to be found in(through?) the package names plane."

 

We do a similar thing with overrides, but I am looking for a tool to support and maintain those overrides.

My problem is when upgrading to a new version, I need to check every override manually and this is something I would like to automate.

 

If the override would know what the original code was, the override could compare itself when loaded over a new version of cincom if the new version is still the same as before.

If not, that override should be marked as to verify.

 

Any help is welcome

 

Mvg

Stefaan

 

 

 

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

---

[hidden email]
May 19, 2011 8:23 AM

Hi all,

 

In a previous post I read:

"Alterations to Cincom code are maintained as overrides in separate packages where the original Cincom package name is postfixed with the string ' patches', so these are branches too but the branch does not have a name as such and is to be found in(through?) the package names plane."

 

We do a similar thing with overrides, but I am looking for a tool to support and maintain those overrides.

My problem is when upgrading to a new version, I need to check every override manually and this is something I would like to automate.

 

If the override would know what the original code was, the override could compare itself when loaded over a new version of cincom if the new version is still the same as before.

If not, that override should be marked as to verify.

 

Any help is welcome

 

Mvg

Stefaan

 

 

 

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

---

[hidden email]
May 5, 2011 6:00 PM

Hi All,

I'm currently working on some code that interprets VersionString as a set of Branches and Versions. I'd like to know what versionString format you use to determine branching in your projects. At Cincom we do the following:

Branch - Version + Branch Version + Branch Version + Branch Version ....
eg: 7.9 - 4 + AR 58932 3

Please post your examples.

Cheers,
Michael

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc