adopt more traditional version labeling

[macMikey]

it would be great if you would use a more traditional version labeling scheme, and then, if a version was dependent upon a particular version of 4d, add that to the readme/release notes. right now, for instance, you have R5 as the version level, but R4 is still in beta, R5 is not available, and it doesn't look like there is anything in R5 that won't run in prior versions. i get that netkit is supposed to be an internal component, but there are features and bugfixes that apply to prior versions, too.

[e-marchand]

Component branch follow strictly 4D one to not fall into dependency hell and to follow R release train (3 months) with chosen and tested features

This component branch 20R5 is for 4D 20R5 (soon in beta after some tests before releasing, maybe it run, but not fully re-tested) Main is already for 20R6 (and not stable with new features)

And as 4D component dev (not this one) we could use new language features by branch (for instance "Try Catch" or other things that could not work in previous release)

[macMikey]

the thing i'm thinking about are when hotfixes, like PR63 hit (assuming that it is accepted), they might need to be applied to multiple versions. since netkit is supposed to be an internal component, i get lining it up with the branches. it just seems like more work to have to cherrypick hotfixes onto each of the supported branches.

[e-marchand]

I understand the point and I somewhat agree We use another VCS before Git and we keep this flat way to proceed.

For my component until there is no real change, I synchronise my 20R. branch with the main. But I am the only one. So cherry pick is the norm. (we have some tools in our BugBase tool to create merge request easily)

[macMikey]

on, that's right. i forgot you guys didn't use git for everyday tasks. nothing to see here. move along.