Strategy moving towards Wegue v2

[chrismayer]

A lot of work has been done, which will result in Wegue v2 since a lot of base dependecies (Webpack, ...) will get a major upgrade. Besides the fact that it is desirable to have the latest versions of the dependencies the current state blocks us from having the latest OpenLayers, which is bad since it is our hardcore mapping library and maps are a central aspect of Wegue apps.

Meanwhile we have a lot of PRs related to Wegue v2, see Wegue v2 which is really great and and which contain a lot of work - thanks to all contributors! 🚀

But those PRs are pending and since we have a lot of them it is quite uncomfortable to use them, if you are interested. To accelerate the moving towards Wegue v2 I come up with the following idea:

At a dedicated date we should create a v1 branch based on the master and and use the master branch for what it is meant to - the current development stream. This would give us the chance to get a away from the pending PRs, not knowing where to go with and having the great work more usable for those who want to. In case you stuck to Wegue v1 in some projects (also me) we (the community) can still maintain and of course use v1. So there is a chance of migrate existing apps from v1 to v2 in a calm way without any hussel.

So long terms short: The current master gets a new name and the PRs get a home and therefore usable in the "new" master. So nothing changes besides 2 branch names, if you don't want to.

My motivation for this: For me recent projects had the requirement to use an up-to-date OpenLayers, which blocked me from using Wegue. Maybe others will also have this problem and prevent us having more Wegue users and therefore a bigger community. I fear that we are dying on beauty (is that an English saying? 😆 ) , in case we do not merge in the great upgrade work of the PRs. I had that in other projects as well, which is sad and discouraging. I personally remember the words of one of my mentors "Release early and often - go out with that 💩 ".

Disclaimer since written word can be interpreted in different ways: This is not blaming anyone - I really like the work already done. I just want to help get things forward and since I am not the guy writing webapck configs - this is the only way to help at the moment.

Any thoughts, especially by @fschmenger @justb4 @ntma @spwoodcock @JakobMiksch and of course anyone else. TIA!

[spwoodcock]

@chrismayer sounds like the perfect solution!

It would be good to have a save state for V1 for those that can't upgrade yet.

We could then move ahead with the V2 merges (v2-beta?), without having to worry about breaking existing functionality.

I currently use a version with the merged PRs for Vue CLI and the OL update - everything seems to be working as intended (at least the basic functionality I have tested, loading in geojson data and styling).

This would pave the way for more PRs (e.g. clustering).

[JakobMiksch]

Creating a legacy branch for v1 sounds reasonable for me. This is an established concept also done in other projects. Thumbs up from my side 👍

[fschmenger]

Thanks Christian for bringing this up. I think this makes perfect sense and I also prefer this over my adhoc proposal to create a branch for next-version. So we basically just do it the other way around which should be more future proof.
What is the best practice on tagging versions in the dev-master then? We use v2-beta until we are finally there or no tag at all?

[fschmenger]

Sorry for not being very verbose on that "versioning / tagging topic" in my recent post. I had a second thought about it during the lunch break so i just wanted to clarify:
Given e.g. the following situation: We have some new features and want to bump up the last stable (v1) release to v1.4. Apparently we would update the the v1-stable branch and insert a tag there. How would we handle this situation in the dev-master then, as inserting a tag 1.4 on top of some changes not going into the v1-stable would be very confusing? I wonder what the best practice is, should the dev-master then always be version-tag free, until a new major version is released? How do other projects handle this?

Apparently this is just an example and will apply also to all future work, since we should come up with a mechanism that we can retain for all upcoming Wegue versions. Curious to hear some insights on this :)

[spwoodcock]

Hey @fschmenger!

Wouldn't it be easiest to add all your updates for v1.4 to master, then create a v1 branch and v1.4 tag at the same time?

We could then move onto v2 development on master, as there will be a save state of v1 and a v1 branch to create hotfixes or cherry-pick onto as required.

Key:
version
branch

[chrismayer]

From my experience in other projects this could be possible procedure:

• Release/tag next v1.x version from master
• Branch away from master as v1 or similar at same time
• Feature development should be focused on master, only in exception cases and for good reasons new features should be added to v1
• Patches and security fixes should be ported (cherry-picked) to v1 from master, if possible. Or be done directly in v1, if it is a v1-only fix
• Possible new releases/tags based on v1 (e.g. 1.4.1) are not back ported to master
• master can remain without releases / tags, when development has a high pace to be more flexible.
• At a certain point we can decide it is the time to go out, maybe with alpha or beta pre-relases

[chrismayer]

Thank you all your for your replies and input! I proposed a possible procedure in the thread above, which is coherent with most of the input of @fschmenger and @spwoodcock . I only tried to formalize a bit and give some additional input.

From my experience this is quite a common procedure and could be adapted while having it in progress, when we see how it works in practice.