Where do we see work for v8?

[trusktr]

I heard there will be async features added to Vim version 8 (encouraged by NeoVim?). I don't see a v8 branch or similar though.

[chrisbra]

work is done in the master branch.

[vim-ml]

On Jul 3, 2016 14:57, "Christian Brabandt" vim-dev-github@256bit.org
wrote:

Closed #900.

The master branch is indeed used as Bram's experimental branch, waiting for
bug reports before a feature is mature.

It would be great if credit were given to Neovim for the concepts vetted
there. So far I have seen no acknowledgement from Bram regarding Neovim,
whatsoever. Why?

---

Justin M. Keyes

[vim-ml]

Justin M. Keyes wrote:

On Jul 3, 2016 14:57, "Christian Brabandt" vim-dev-github@256bit.org
wrote:

Closed #900.

The master branch is indeed used as Bram's experimental branch, waiting for
bug reports before a feature is mature.

It would be great if credit were given to Neovim for the concepts vetted
there. So far I have seen no acknowledgement from Bram regarding Neovim,
whatsoever. Why?

What are you referring to? I haven't used anything from Neovim, but
perhaps people who send me patches did.

Some of the well known MS-Windows errors:
ESLEEP Operator fell asleep
ENOERR No error yet
EDOLLAR OS too expensive
EWINDOWS MS-Windows loaded, system in danger

/// Bram Moolenaar -- Bram@Moolenaar.net -- http://www.Moolenaar.net \
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \
\ an exciting new programming language -- http://www.Zimbu.org ///
\ help me help AIDS victims -- http://ICCF-Holland.org ///

[ghost]

But this highlights a much deeper problem.

What was being published as patches for 7.4, is actually a convoluted mess of pre-8 stuff and 7.4 patches.

It is impossible to tell which of those 2367 diffs for 7.4 are actual 7.4 patches and which of these are pre-8 stuff.

As a result it is impossible to create a proper final 7.4 release without the 8.x stuff.

Where is the 7.4 branch? Where is the 8.0 branch? Doesn't exist.

Too late now.

[vim-ml]

Am 2016-10-05 12:06, schrieb MadMaverick9:

But this highlights a much deeper problem.

[...]

Where is the 7.4 branch? Where is the 8.0 branch? Doesn't exist.

That is not how development happens. I fail to see, why this is a
problem.

[fritzophrenic]

Am 2016-10-05 12:06, schrieb MadMaverick9:

But this highlights a much deeper problem.

[...]

Where is the 7.4 branch? Where is the 8.0 branch? Doesn't exist.

That is not how development happens. I fail to see, why this is a
problem.

It makes it difficult (or impossible) to tell the difference between changes that make Vim more stable by fixing bugs, etc., and changes that make Vim less stable, by adding experimental features.

With most other software, updating from 7.4.1234 to 7.4.1235 is almost always "safe". You only would need to worry on an upgrade from 7.4.x to 7.5.x or 8.0. With Vim that is not the case. 8.0 is released, and already had a bunch of bugs fixed, but since there is no "stable" branch nobody can know when it is safe to pull those changes. This leads to problems like outdated versions of Vim in package manager repositories, since the maintainer of the package would need to pay close attention to the vim_dev mailing list or patch notes in order to know which version is the last "stable" version.

[chrisbra]

What follows is purely my opion and of course Bram has the final say, so please take the following with a grain of salt.
True, we don't have a stable branch. But even if there would be a stable branch, one would still have to follow development cycle closely to be sure, that breakage is not done on purpose. So it would not help much.

However, I think if we would go with creating several branches, we might end up putting more work on Brams shoulders which will in the end hurt more then it will help.

[fritzophrenic]

I think what might help in the next release, would be to start calling it 8.1 (maybe alpha or beta) prior to any unstable features, rather than after the features are made stable. Then there is a clear break-off point. Looking at the Mercurial history, didn't Bram do something similar for the 7.0, 7.1, and 7.2 releases? The 7.3 release even got it's own branch, it looks like.

[ghost]

Where is the 7.4 branch? Where is the 8.0 branch? Doesn't exist.

That is not how development happens. ...

Says who?

Please look at the links below and see how development happens.

Where do you keep the bug fixes/patches for 7.4 that do not introduce new 8.0 features?

http://ericsink.com/scm/scm_branches.html
https://docs.python.org/devguide/devcycle.html#in-development-main-branch (master)
https://docs.python.org/devguide/devcycle.html#maintenance-branches (for example: 7.4 branch)

Interestingly fritzophrenic already spelled out the problems I have with your approach.

I am quite happy I am not the only one who has a problem with the current approach of only having an experimental master and no stable release branches.

And if vim is 100 percent experimental and does not have stable releases, then you should make that clear on www.vim.org. I am not special, so there are plenty of other people out there who will assume that updating from 7.4.1153 to 7.4.1218 will give them a more stable vim. But that is obviously not the case since in that range JSON was introduced as a new experimental/future feature.

You know - if you're the only developer and the only user of a program, then this approach of having only master is Ok. But for a big project like vim, I would've expected something better.

[brammool]

Using a development branch has advantages and disadvantages. Previously I would make alpha and beta releases before bringing out a minor or major release. The effect is that problems then get reported after the release got out, because not enough people tried out the pre-release version.

The gradual adding of features for Vim 8 has worked well, we got early feedback and there were very few regressions in existing features. Only two real problems were found after the 8.0 release, one of them was of the version number changes so would not have been caught in any way.

Most of the new features were around job and channel, and the help clearly stated that this was still being worked on. I don't think anybody had an actual problem with that. We can mark new features as "experimental" if needed. In my opinion that works much better than using a branch and merging it at some point.

[ghost]

using a branch and merging it at some point.

Huh? That don't make sense.

You already have a development branch (experimental branch). It's called master.

You should have created a release branch and merge any bug fixes from the development branch aka master into the appropriate release branch. It's called backporting.

Only two real problems were found after the 8.0 release

So - these two bug fixes should have been backported into a 8.0 release branch. But like I said earlier: - it's too late now.

And the stupid thing is - because of the way you did things with 7.4 and now 8.x important information is gone/not available/lost forever, namely which patch/commit was a pure bug fix and which commit was an enhancement/experimental feature. So even though you're using a source control management system, you've lost valuable information.

And the sad thing is that you used to do it in a better way: https://sourceforge.net/p/vim/code/HEAD/tree/branches/

because not enough people tried out the pre-release version.

And yes - I choose to ignore this sentence, because QA is the developer's problem. Users & distro maintainers care more about stable code. The releases directory here is a joke me thinks. It's just a re-packaging of the commit you just did. It doesn't tell users anything about which tar.gz is unstable or stable.

Sadly I could just keep on going ...

We can mark new features as "experimental"

So adding the word "experimental" in the commit log is the proper way how to use an scm nowadays? Oh my ...

So what was the last 7.4.xxx patch that did not introduce a new 8.0 feature?

http://ericsink.com/scm/scm_branches.html
https://docs.python.org/devguide/devcycle.html#in-development-main-branch (master)
https://docs.python.org/devguide/devcycle.html#maintenance-branches (for example: 7.4 branch)

[vim-ml]

Am 2016-10-06 07:25, schrieb MadMaverick9:

And yes - I choose to ignore this sentence, because QA is the
developer's problem. Users & distro maintainers care more about stable
code. The releases [1] directory here is a joke me thinks. It's just a
re-packaging of the commit you just did. It doesn't tell users
anything about which tar.gz is unstable or stable.

Sadly I could just keep on going ...
[...]

Guess what, Open Source has always been about freedom. That includes the
freedom to develop
what has been proven to be successfull. And since the development of Vim
predates those of
distributed VCS which made the branche/merge/rebase workflow successfull
by at least one decade
there is nothing wrong with continuing that approach. Now that might not
satisfy everybody.
But hey, such is life.

http://ericsink.com/scm/scm_branches.html
https://docs.python.org/devguide/devcycle.html#in-development-main-branch
(master)
https://docs.python.org/devguide/devcycle.html#maintenance-branches
(for example: 7.4 branch)

Who are you that you are trying to dictate how we develop? The issue has
been closed
for a reason. I see no point in discussing this further.

Best,
Christian

[ghost]

I am a Nobody.

Don't worry - you will never hear from me again.