Clarity on vRO version control

[carl1]

Does the below look accurate"?

Workflow has version 0.3.1

Developer A increases version to 0.3.2

Developer A makes update A

Developer B increases version to 0.3.3

Developer B makes update B

Version is reverted to 0.3.2:

Change A is not included.

Change B is not included.

Version is reverted to 0.3.3

Change A is included.

Change B is not included.

That seems to be what we are experiencing (loosing code changes).

Carl L.

[iiliev]

Which vRO version is this?

Also, what is the point of a developer increasing the version BEFORE making a change? The version should be increased AFTER making a change. Otherwise, in your example, what would be the differences between versions 0.3.1 and 0.3.2 (as version is increased to 0.3.2 before updates A and B)?

[carl1]

This is 7.4

When our developers start a project, they first set the release number that they want to release under and then make the changes for the release.  We just want to make sure we understand that those changes are NOT getting captured in their release number unless they also do a new release number when they are all done.  If they don't make the first version increase, then they might forget that they modified that particular workflow and thus they may not put it into their promotion package.

Also, for example, if they think they are all done, increase the release number and then find a bug, they they MUST remember to increment the version again after they fix the bug; even though they did not actually released A.

Clarity is a good thing,

Thanks Ilian.

[iiliev · Accepted solution]

OK, I got the point of your developers, but their approach would have its own set of issues.

Here is an example. The developer increases the version to 0.3.2 with the intent to release this version. Then he makes some changes in the workflow and passes the result to the people who have to test and approve these changes. If they find some problem, they would return a bug report to the developer, who would fix the problem by making some more changes and would pass again the changed workflow for testing. So this procedure would take several iterations to resolve all the newly introduced problems, and during it the workflow will remain at version 0.3.2, forcing the developers to remember which 'revision' they have passed for testing in the N-th iteration and what changes were done exactly in this revision. This is very error-prone and non-deterministic approach.

And that's not the way the other system that track changes work. Take for example source control systems like Git. when you make a commit, Git 'chekpoints' the current state with the changes that are made until the moment you commit.

As for the version numbering, it shouldn't be a big problem because:

• it is not mandatory to release consecutive versions, so if your previous release was at version 0.3.1, it is OK for the next release to be not 0.3.2 but something like 0.3.17
• you can adopt some convention for release/dev versions; for example, you could use version number 0.3.0, 0.4.0, 0.5.0, etc. for 'official' releases, and in-between version numbers like 0.3.1, 0.3.2, 0.4.1, etc. for testing/dev builds.

[carl1]

Thanks so much Ilian!  Like I said, clarity is a good thing and I just need to make sure our team is doing their rev controls properly.

Thanks again

Carl L.

BTW, when I have to speed-delete all of my VRO community emails (usually when it reaches 100 unread or more), yours are the only entries that I read.  Your participation in this forum is invaluable.