RFC: Prepare for 0.3 release, adopt semver versioning and a fixed release cycle

[lebensterben]

The main branch is in stale for quite a long time while the develop branch is becoming significantly different from it.

I don't see real benefit on keeping both 0.2 and 0.3 branch as in current state. For the development of this project in the long term, I'm proposing the following:

• We need to prepare for a 0.3 release and make it as main branch.
  • The 0.2 branch would become a legacy branch.
  • A new develop branch would be created, for development on top of main branch (that is on 0.3).
• To prepare for the 0.3 release, we need to set some deadlines that would determine what would be included when it's released.
  • We can make a temporary pre-0.3 branch, which would accept new PR from develop branch until a deadline, for example, Jan 1 2021.
  • Upon this deadline, new PR will still be accepted on develop branch, but pre-0.3 branch will only accept bug-fix and documentation updates.
  • We need another deadline, say Feb 1 2021, which determines a specific window from the first deadline, and during which we will have the opportunity to receive community feedback and do some last minute patches. But no new features would be added.
• When the time comes, we will rename pre-0.3 branch to main, and I propose to adopt semver versioning and a fixed release cycle.
  • Since no public API is likely to be formalised, we won't increment the major version number. But only minor and patch version number.
  • For every 4 weeks, the new main branch will merge with the develop branch, and if there's any new feature added, we will increment the minor version number. If there's only bug-fix or documentation update, then we will increment the patch version number.
  • Between the 4-week release cycle, the main branch will only merge bug-fix from develop branch.
  • That is to say, new features will only likely to be included every 4-month.

[allentiak]

Whereas this plan sounds reasonable, I wonder how feasible is to actually implement the changes required to adopt it...
On the other side, the de facto development model for the last few years has been a rolling release... What about officially acknowledging this?
(See #13248.)

[lebensterben]

Rolling release is okay for develop branch, but we still need a more stable branch with traditional a release model.

[allentiak]

Just my opinion, but I think the question is not whether a non-stale stable branch is needed (most likely, it actually is!), but about the feasibility of actually implementing the change :-)

(I might be wrong about this, but when I think about the huge adoption cost of this proposal - this is, changing the workflow used by most, if not all, of the hard-working main contributors-, I simply cannot see it being adopted successfully.)

[lebensterben]

What part of the changes do you think is costly?

[max-sixty]

What part of the changes do you think is costly?

I mean this the politest possible way — why do you think there have been no stable releases for three years? I would rate: stable release > rolling release > "aging stable release with de facto rolling release for most (almost all?) users".

If there's a realistic plan to take Spacemacs to stable release without making tradeoffs on the project's velocity, then great! But I think most users would be satisfied with the project on rolling release, particularly if it were less costly for maintainers. That Spacemacs has been so successful in the past three years is a good case that it's possible.

[allentiak]

I think there are two factors here, more related to the *adoption* of the proposed charge than to the perceived benefits of that adoption itself (which I am not evaluating here, BTW :-) On the one side (as I said before), inertia. Radically changing the way *contributors* have been working for the last two years or so is costly by itself, as reaching to an agreement would take time and energy. Moreover, I think that (even if a new workflow is adopted) keep using that new workflow *without gradually returning to the old one* is the most difficult part. Again, just my opinion. And I could be wrong :-) Probably the best would be to hear what the main developers have to say about this?

…