Organizational: scraping visions, embracing semver

Hello!

During way to 0.14.x I started to use proactive "visions" approach, where the mission statement of sort was create for an upcoming versions. This way, for example, 0.15.0 was defined as "the version where package management will be made much more smooth and streamlined", 0.16.0 is "version with working debugger and User Manual", and there is a vision for 0.17.0 as well.

On the other side, there is semver (the 0.0.x, 0.x.y and x.y.z versioning scheme) that says clearly that everytime there is a breaking change, x (or the zero before it) must be increased. That's the idea behind semver, so that one knows that e.g. 0.14.17 is compatible with 0.14.3 and it can be upgraded without (visible) costs. That is of course, not true for 0.14.x line of Amber, there were breaking changes.

The "vision" thing failed - 0.15.x was delayed too long and the goal is not fulfilled yet.

So, I am changing the strategy, abandoning visions (and deleting milestones for 0.16 and 0.17), and embracing semver properly. Any time there is a breaking change, I will increase x. That means, there may be 0.56.0 at the end of the year, OTOH, upgrading should be less fearful, as compatible versions will be compatible and incompatible ones would need migration by hand, anyway.

When we're at migration, I just felt 'react-native upgrade' a few times - a command that updates the skeleton files of react-native project after upgrade - and when conflict appeared, I always selected "a" (replace all without asking) and then just went over diffs in IDE and reapplied my changes back into new skeleton.

Do you think this is feasible for you as well (then, I could try to make 'amber upgrade' by more or less just doing 'amber init' with existing title, repo etc. and copying everything back; after which you can run 'grunt' to recompile and you should be done with the migration in majority of upgrade scenarios).

Herby

--
You received this message because you are subscribed to the Google Groups "amber-lang" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.

I am all for proper semver.

That's what one expects for a project making use of js tooling IMV.

Phil

On Mon, Jan 25, 2016 at 10:22 PM, Herby Vojčík <[hidden email]> wrote:

Hello!

During way to 0.14.x I started to use proactive "visions" approach, where the mission statement of sort was create for an upcoming versions. This way, for example, 0.15.0 was defined as "the version where package management will be made much more smooth and streamlined", 0.16.0 is "version with working debugger and User Manual", and there is a vision for 0.17.0 as well.

On the other side, there is semver (the 0.0.x, 0.x.y and x.y.z versioning scheme) that says clearly that everytime there is a breaking change, x (or the zero before it) must be increased. That's the idea behind semver, so that one knows that e.g. 0.14.17 is compatible with 0.14.3 and it can be upgraded without (visible) costs. That is of course, not true for 0.14.x line of Amber, there were breaking changes.

The "vision" thing failed - 0.15.x was delayed too long and the goal is not fulfilled yet.

So, I am changing the strategy, abandoning visions (and deleting milestones for 0.16 and 0.17), and embracing semver properly. Any time there is a breaking change, I will increase x. That means, there may be 0.56.0 at the end of the year, OTOH, upgrading should be less fearful, as compatible versions will be compatible and incompatible ones would need migration by hand, anyway.

When we're at migration, I just felt 'react-native upgrade' a few times - a command that updates the skeleton files of react-native project after upgrade - and when conflict appeared, I always selected "a" (replace all without asking) and then just went over diffs in IDE and reapplied my changes back into new skeleton.

Do you think this is feasible for you as well (then, I could try to make 'amber upgrade' by more or less just doing 'amber init' with existing title, repo etc. and copying everything back; after which you can run 'grunt' to recompile and you should be done with the migration in majority of upgrade scenarios).

Herby

--
You received this message because you are subscribed to the Google Groups "amber-lang" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "amber-lang" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.