Versioining scheme for 3rd party code (incl. Poll)

[jtuchel]

Hi DevTeam,

I would like to ask you to think about your versioning scheme of third party code, like sUnit or GLORP.
I'll try and make my argument short...

I was looking into a problem I had with sUnit due to "missing" failure information in TestResults (I need to report test results to a Hudson Build server) - read more about this on my blog at http://joachimtuchel.wordpress.com/2011/01/18/what-sunit-could-learn-from-junit/). The answer to my problem is that sUnit should do a "back-port" of the TestFailure class from jUnit. This is not very hard, I plan to look into this over the next few days.

BUT there are a few factors that keep me from doing it in VAST (which I'll do nevertheless, because I need it there):
* There is no easy way of pushing my changes out to Squeak or VW from Envy
* I have no idea what version of sUnit ships with VA ST, so I have no idea what version to port my stuff to when I want to propose it to the sUnit project members. I can only send them source code and tell them to look how it fits into their latest version

Especially in Frameworks like GLORP or Seaside, the version of the original can be extremely important if I need to ask for help. If you look at the Seaside mailing list, one of the most frequent questions asked is "What version are you using, and on what platform". In GLORP this is currently especially bad, because the version currently shipped with VAST is about 5 years old, so if I asked questions about problems on any forum, people might have big problems understanding my problem anyways...

So I vote for a redo of versioning for third party code that is shipped with VAST. Please don't give it a Version Number that reflects the VA product version, give it the version number of the source (maybe extended with some VAST specific part, if that's really necessary for your internal buid processes).

This would also make life on/with VASTGoodies easier, because we could have ports of newer versions of the original from Squeak published there with a "real" version number (in the context of the project that produced the code).

What are other users' thoughts on this?
(You have to be a registered user and logged on to make a vote in the poll)

[wembley]

Joachim -

OK, let's start with "What is the version number of the original project?"

• The SUnit project publishes configuration maps with version numbers, so it is at least theoretically possible to use them as VA Smalltalk configuration map names (as long as we make no changes to the content before shipping). In addition, I defy you to tell me what the version of SUnit in VW or Pharo/Squeak is -- it is in no way the 'official' version available from Niall.
• There really is no Seaside project version numbers that we could use as configuration map versions. For example, VA Smalltalk V8.0.3 will ship a port of Seaside 3.0.2, but it is not exactly 3.0.2 since we make changes and additions.
• The version of GLORP we ship may or may not be closely related to a particular (old) VW version (only Niall knows for sure) -- it is certainly not the same.

So, for those who vote for using the 'original version', please weigh in with some ideas on what you think that actually means.

[marten]

I would like to have the following one:

the version number used (for the configuration map) should have the name of the VA version, when the code was published e.g "V 8.0.3" - just to know, WHEN it has been official available for VA.

the version number of the original code, where it has been spinned of - or the author thinks it is (functionally) near by.

That would lead to something like V 8.0.2 (3.0.2) [122] or V 8.0.2 (3.0.2-VA-MSK-001) [122] or V 8.0.2 [122] Squeak 3.0.2-VA-MSK-001 (VA indicates that this is Smalltalk code for VA, MSK indicates my person and the number is a simple patch version) (actually I would prefer the last version - because then ENVY does the work for my own patches).

Therefore for the original code published by Instantiations in a product I would like to see stuff like
" V 8.0.2 [122] Squeak 3.0.2-VA-INST-001".

[jtuchel]

HI Marten,

good suggestion. But insufficient, because as John states (thanks John for pointing that out), for some cases it's not sufficient.

Let's take a look at Squeaksource.com and search for ConfigurationOfSeaside30, which is the "official" starting point to load Seaside into a Pharo image. You will find version numbers like this:

ConfigurationOfSeaside30-DaleHenrichs.280

Let's assume a Metacello config is somewhat an equivalent of a Config Map. If this was the version from which a port to VASt was drawn, we'd have to have this full version name integrated into the version name of our Config Map, because there may be changes between ConfigurationOfSeaside30-DaleHenrichs.280 and (a hypthetical) ConfigurationOfSeaside30-JamesFoster.281 that are relevant in discussions with the Seaside crowd. The answer to a question on a Seaside Board might be: "upgrade to ConfigurationOfSeaside30-JamesFoster.281 because the issue was fixed there". Even if doing so is not so easy, I still know I can either try to port the changes to VAST myself or wait for a new build from INstantiations or some other kind VAST guru.

My point is probably quite irrelevant if we think of the VAST community as it's own ecosystem, but this is neither what I think we should be, nor what I think we will be over time. There are so many nice tools coming from other Smalltalk dialects that (can) make our lives easier, so we should avoid boiling in our own soup. If I have a Seaside problem and ask for help and say: "well, I use the version shipped with VAST 8.1", I keep most Seaside users from knowing what actual version I use, so I probably will not get any help from a Pharo or Squeak or VisualWorks user.

And to answer John's comment together with yours:

The version of Seaside I use is not Version 8.0.2 [122]. It is based on a Version 3.0 b1 whatever, and it shipped with VAST 8.0.2. That's just not right. I know at least Seaside is being ported from Squeaksource (but not by using a Metacello-Cofiguration), so the source is not Squeak, but SqueakSource. The person who ports a piece of code knows which version from what source she uses. There is an official Version 4.0 of SUnit on Sunit.sourceforge.net, and the version we use is not 8.0.2, but a descendant of V4.0.

Same goes for Glorp. Maybe teh info which exact version has been used for the currently shipped version of Glorp has been lost in time, but for the next version which will be based on a 0.4 or even 7.7-version of GLORP, and we need that info at a prominent place.

So, John, you are right, this is a very complicated topic, and I am afraid there is no perfect solution. Maybe I want way too much and haven't thought of all the consequences. My fear, on the other hand, is that the very active communities like the Seaside clan will often answer our question with a shrug of their shoulders because they won't get the info they need to identify our problems. We cannot assume that Seasiders have a copy of (insert whatever Smalltalk platform you want) installed to look into problems.

Just a thought

[benvandijk]

Hi Guys,

I prefer to keep the va version numbers like 8.0.3 to keep track of the shipped versions.
For code that is shipped and/or ported by Instantiations.

Third party software developed for VA should keep their original versions.

Software ported to VA from other dialects can use the comments in the configmap
to show the heritage "based on Sunit 4.0, adapted by instantiations

[marten]

Yes - everything else seems to be pretty difficult and I have also another reason for that: IF it is part of the product (not an unsupported goodie), then Instantiations is responsible to make it work as expected by the community and if its broken they have to fix it quick and publish the fix - and not wait until the next release. Normally I do not have to look at Seaside of Pharo - because I use Seaside of VA.

Joachim: the problem that we have to know, which base-version of Seaside we are using under VA and to look more than once at other Seaside platform to fix some problems are due to other problems ...

I prefer to keep the va version numbers like 8.0.3 to keep track of the shipped versions.

[jtuchel]

Marten,

I am not complaining about the fact that there is a need to talk to the community for help.
I think it is a fact that the chances of getting help for Seaside and GLORP are much better when asking the community than asking only in our VAST ecosystem. We'll see bugs that are in the VAST port only, but we'll also encounter problems that are bugs in the original project that is written on Squeak/Pharo/VisualWorks/GNUSmalltalk/... . In such cases we need a way to find out easily which kind of problem we're facing WITHOUT having to install the original platform. Therefore we need the version numbers of the original. Even more so if you are interested in committing changes back - which is even more complicated.

Maybe I am asking too much and keeping that info in a prominent place like the Config Map comment is sufficient.
My initial thought was related to the facts that
* 3rd party products (be it o/s or commercial) have their own lifecycle
* Instantiations is (at least tghey said so) working on bringing out releases of Seaside or other frameworks between VAST releases. The reason for these can be problems introduced in the port or coming from the original.

So I agree this is very complicated and we probably have no better way to solve this than to keep a reference to the original version (where applicable) at a prominent place and go for VAST-specific version numbers that are related to the Product version...

Joachim