Version increment on date prefix

[Bob Nemec]

Is there a way to have duplicate version names increment on a date prefix if the user initials are the suffix? For example...

• 2026-04-11 BN
• 2026-04-11.1 BN
• 2026-04-11.2 BN
• …

Otherwise a duplicate version increment would be 2026-04-11 BO 

We could put the user initials as a prefix, but the date displays better when looking at history. 

btw: we've successfully used Tonel to import 9632 classes with 54846 methods from VW to VAST ... thanks to help from Mariano and Esteban

[Esteban A. Maringolo]

Hi Bob,

The current version name increment logic is limited, as it only increments the value of the last character.

A configurable formatter could address this by allowing you to define how the string is parsed and which parts should be incremented. I have noted this as a potential enhancement for future development.

Regarding the Tonel migration, I am glad to hear you were successful. It is impressive that you were able to navigate the dialect differences so effectively.

Best regards,

Esteban Maringolo VAST Consultant Senior Software Developer  emari...@instantiations.com  @emaringolo  /emaringolo  instantiations.com

--
You received this message because you are subscribed to the Google Groups "VAST Community Forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to va-smalltalk...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/va-smalltalk/b773a11d-d36b-4e75-b20c-e2787f658e3dn%40googlegroups.com.

[Marcus Wagner]

Hi Bob, 

I have a snippet in an app providing this. Attached is an app to import (applies the patch when loaded, removes the patch when unloaded).

Dont know if this zip here survives travelling as attachment, let me know if not. Code is tested on data of your example given (BN) above.

Kind regards

M

[Bob Nemec]

Hey Marcus, 

It works in isolation, but not with a date + id template. But you got me curious, I'll look into your code a bit more...

StsPowerTools defaultDateFormat: '%Y-%m-%d'.
StsPowerTools defaultVersionNameTemplate: '%D %I'.
'2026-04-14.2 BN' stsNextVersionName   ->  '2026-04-16 BN'
'2026-04-16 BN' stsNextVersionName  -> '2026-04-16 BNa'
'2026-04-16.1 BNa' stsNextVersionName  -> '2026-04-16 BN'

StsPowerTools defaultVersionNameTemplate: ''.
'2026-04-16 BN' stsNextVersionName  -> '2026-04-16.1 BN'
'2026-04-16.1 BN' stsNextVersionName  ->  '2026-04-16.2 BN'
'2026-04-16.2 BN' stsNextVersionName  -> '2026-04-16.3 BN'

A blank template is not optimal since it misses the date value we use. 

Bob

[Esteban A. Maringolo]

Hi Bob and Marcus,

Following up on this discussion and our internal requirements, I wanted to let you know that the next version of VAST will introduce an EmVersionNamingStrategy class.

This will include a default singleton and allow developers to define their own subclasses. You will be able to implement custom versioning and parsing algorithms to increment versions according to your specific needs.

Best regards,

Esteban Maringolo VAST Consultant Senior Software Developer  emari...@instantiations.com  @emaringolo  /emaringolo  instantiations.com

--

You received this message because you are subscribed to the Google Groups "VAST Community Forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to va-smalltalk...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/va-smalltalk/246e7fed-b74e-4f59-969f-7956b8863d6an%40googlegroups.com.

[Marcus Wagner]

Hi Esteban and Bob

Esteban, fIrst, thanks for the announcement of a configurable strategy, as this is a solid way to provide enough room for individual solutions. 

Any rigid general rule won't do, as my snippet has proven, as so many (not communicated) assumptions have to be considered, too.

Many cases here depend on individual requirements, based on the given template support, this will give anybody the opportunity to taylor a solution to his needs.

Bob, if you need s.th. in between, before arrival of the strategy, let me know. 

I intentionally did not assume any template in my suggestion. And even with the information you gave above (to be based on date and id template), other important details are not fixed yet.

e.g. when to create a branch, the position and structure of the version, ... 

Up to know there was the hidden assumption that the version string ends with scheme to be incremented (but the %D %I does not). 

My simple approach thus increments %I (or whatever is at the end of the template, I did not orientate on any place holder).

A strategy is the answer to solve this and to avoid other pitfalls, like incrementing the wrong part or even to make use of my hack to patch an existing version code. 

Kind regards

M  

[Marcus Wagner]

Hi Esteban,

I suggest to think about another important consequence and follow up: a release strategy pattern of some sort, working hand in hand.

This is the opportunity to do so, as versioning is the half of the provisioning, releasing the other part.

The planned version strategy opens a plethora of consolidation decision problems: as example, what to be released (23-03-80 1 AM or 24-03-80 2 ZZ or even 23-03-80 1 MW)???

The original versioning dialogs originally where placed exactly in the middle of the (then only) screen, in modal mode locking any other access to this image, with a final remark if nothing was released.

Instantations enhanced this long time ago: support to add comments, version suggestions, multi screen support with different positioning and size, removal of the "nothing released", but still remaining modal to kieep image and repository consistency.

In the consolidation, given e.g. 2 or more versions with such new names as a result of the planned strategy, the given release/versioning won't suffice.

Occasionally, as a release manager, you have to look into the tree of editions (with the new names and the time stamps) to decide which the existing editions has to be released.

The name of the version alone won't help anymore as a follow up of the versioning strategy support.

Once upon the time I had a version dialog plug in (showing the edition hierarchy) to cover this, dialogs which I provided Instantations at your free disposal. 

This plugin used the same patching mechanism to replace the existing version dialog hierarchy (of classes, applications and configuration map).

It used the same pattern - eg. that also can be covered by the strategy pattern in the future.

Please consider this also to be part of this renovation. 

I foresee a demand of decision support as consequence to the given the new flexibility of new names (and many situations which now might become indecidable - like what is the latest or the right edition with new version names to be released).

Let me know if I can assist you in that. 

Kind regards

M

PS: version names are special species. Once upon a time it was a simple, unstructured number (OS level, eg.), then it became a number structure, decorations have been added (like date, name initials) and now result of a strategy pattern.

The initial purpose tends to be forgotten - given two versions to be able see which of them is more actual.

[Marcus Wagner]

As announced, find the version prompter plug in / patch attached here. It supported a complex integration of a lot of conflicting development threads into one consolidated trunc in a huge project.

Some remarks: representing the editions tree was experimental, using several different hierarchy controls which were used at that occasion. 

This app adopts to whatever has been loaded (e.g. if WindowsBuilder/Widgets runtime was loaded or not).

In this context, I refer to the branch/undo button. This support targeted exactly the  2026-04-16 1.0 increment to  2026-04-16 1.1 or to  2026-04-16 1.0.1, whether versioning had to branch or not.

The original OTI / IBM version response is revoked.

And the whole thing worked as indepent as possible from the actual template mechanism.

The app is more than 10 years old and was unused since then, so it may fail because of all the changes happening since then.

Kind regards 

M

[Bob Nemec]

Nice... it works nicely. 

Thank you.