ycm-core / YouCompleteMe

A code-completion engine for Vim
http://ycm-core.github.io/YouCompleteMe/
GNU General Public License v3.0
25.45k stars 2.81k forks source link

Create stable, testing branch #2653

Closed spavlovich001 closed 7 years ago

spavlovich001 commented 7 years ago

Please, create stable, testing branch. Stable - for debian stable, testing - for ubuntu\debian testing. Latest commit youcompleteme not work in debian stable.

micbou commented 7 years ago

Our policy is to support the latest LTS version of Ubuntu which is 16.04. Please update your Vim to 7.4.1578 or later.

bstaletic commented 7 years ago

@vasyapupkin123456 You can always git reset to a commit that works for you.

spavlovich001 commented 7 years ago

why our policy is to support latest LTS of ubuntu ? Why not latest debian stable ?

bstaletic commented 7 years ago

@vasyapupkin123456 Debian 9 has been in full freeze since mid february. Debian should release the next version very soon. As for YCM supporting Ubuntu LTS, well, that has a release cycle of 2 years. Deban 8 was released in 25th of April in 2015. Since then a bit more than two years have passed. Being honest YCM doens't switch to supporting the next Ubuntu LTS until 6 months pass after release.

As for micbou's suggestion for updating Vim, that shouldn't really be an issue. Even if there is no released package for Debian, I am sure there is some unofficial PPA. In case you don't trust PPA's build Vim yourself. These days building Vim shouldn't take too long on any machine out there. And I tend to assume that YCM users are not using it on servers so even installing a few packages to build it should be a non-issue.

spavlovich001 commented 7 years ago
  1. in debian stretch(debian testing now) vim8 build without python2. I have some problem in vim8 in stretch in youcompleteme(I'm upgrade to stretch, but revert to jessie).

  2. What ppa support 7.x release for jessie ?

bstaletic commented 7 years ago

YCM works fine with python3, so f you have trouble making it work, read the README.md and if you still have issues ask for help on gitter or in aa new issue report.

As for PPA, I have no idea, I'm an Archlinux user. You'll have to do a bit of googling to find that out. Also, there is no significant difference between Vim 7.4.600+ and Vim 8.0.0000+.

spavlovich001 commented 7 years ago

With this situation(support ubuntu lts), the youcompleteme will always not work on the debian stable. The developers, I hope, know about the semantic versioning?

micbou commented 7 years ago

in debian stretch(debian testing now) vim8 build without python2. I have some problem in vim8 in stretch in youcompleteme(I'm upgrade to stretch, but revert to jessie).

I installed Debian Jessie in a VM and upgraded it to Stretch by replacing jessie with stretch in /etc/apt/sources.list then running sudo apt dist-upgrade and it worked. I just had to install the vim-nox package in addition to the ones required to build YCM (git, cmake, g++, and python-dev)

With this situation(support ubuntu lts), the youcompleteme will always not work on the debian stable.

When Stretch replaces Jessie, YCM will support Debian stable without any issue. We are not going to increase the Vim version requirement each time a new LTS version of Ubuntu is released. In fact, we try to keep the version requirement as minimal as possible but when a Vim feature is available in a more recent version and using that feature would significantly improve the user experience (the timers feature in that case), we have to make a choice between supporting older versions of Vim or improving YCM. Supporting the latest LTS version of Ubuntu helps us in this choice.

The developers, I hope, know about the semantic versioning?

I don't see how semantic versioning would help when all Vim plugin managers fetch plugins on the tip of their master branch and none of them support version constraints.

spavlovich001 commented 7 years ago

Ok, create stable branch. In this branch - support oldest vim(centos stable & debian stable) and create testing branch(for current ubuntu lts and debian testing and centos testing and other distr). Or in stable branch - support stable distrib and in master - testing distrib. If you create stable branch, I can add to vim-plug: Plug 'Valloric/YouCompleteMe', { 'branch': 'stable' } and don't warry about not work youcompleteme after update plugins. Otherwise, I need to keep track on which commit the package stopped working properly. What problem create stable and testing branch ?

puremourning commented 7 years ago

Our stable branch is called 'master'

spavlovich001 commented 7 years ago

@puremourning, Please read the whole topic from beginning to end

puremourning commented 7 years ago

I have. And I feel like the point has been made.

How many stable branches do we need? One for each OS? One for each distro? One for each flavour of each distro?

spavlovich001 commented 7 years ago

@puremourning. The essence of the problem: I have not working youcompleteme on debian jessie. The next release of debian stretch will be in x months.

The problem grows due to the fact that versioning in the vim is incorrect. In vim versioning of the major.minor-patch_number. And should be a major.minor. This is what raises these very situations that have developed now. You, too, do not have versioning. It should be. So that I and other users of the youcompleteme can put the plug 'Valloric / YouCompleteMe', {'branch': 'stable'} or Plug 'Valloric / YouCompleteMe', {'branch': 'some_version'} and guaranteed to receive a working version.

Please read semantic versioning and add major.minor version to youcompleteme(add branches). And be guided in the work by semantic versioning

PS: In general, I do not even believe that such a serious product has to discuss such things. No versioning - users will receive a non-working product on their distribution at certain points in time. It's bad or good - it's up to you.

vheon commented 7 years ago

Ok, create stable branch. In this branch - support oldest vim(centos stable & debian stable) and create testing branch(for current ubuntu lts and debian testing and centos testing and other distr).

Aside the whole "use semantic versioning" thing, which I actually don't understand the importance here this is the thing that puzzle me the most: who decide what il "old" and what is "new"? I mean you happen to work with Debian stable so you say in the "Stable" branch we should support what you use; fine, then comes someone else and say that "oldest vim" might be RHEL 6 because in the Enterprise is actually still used, so we should support that as a base. You can see that this goes nowhere very easily as pointed out by @puremourning

How many stable branches do we need? One for each OS? One for each distro? One for each flavour of each distro?

Plus, working for a company that does a lot of support when I read "support oldest vim" I read that for each freaking branch we should keep patching so a fix that we just put on master has to be backported to every single branch... Well, no thanks.

spavlovich001 commented 7 years ago

@vheon ,

  1. It is very easy to check scripts which versions of vim are with which patches installed on current stable release. And version based on this.
  2. The current stable version: centos7, debian jessie, rhel7 (not rhel6). Who is that in production - it does not matter. It is important that the current stable release
  3. With versioning, you can easily separate which version of youcompleteme will run on rhel7 and on rhel6 (look at point 1)
  4. The issue of supporting older versions is considered separately. You can commit them if this is a critical bug, but you can declare old versions unsupported, for your choice

Without versioning, it is not at all clear on which commit youcompleteme will work, and on what - no. In general, unstable behavior as a whole.

oblitum commented 7 years ago

@vasyapupkin123456,

Semantic versioning would solve this just like sticking to hash commits: A given semantic version may or may not work on a given system, just like a given hash commit. In any case, it would be the user the one responsible to assure that because YCM devs are not testing it in all machine flavors, hence it wouldn't make any difference, it's you that puts the stick, be it tag or hash.

  1. in debian stretch(debian testing now) vim8 build without python2. I have some problem in vim8 in stretch in youcompleteme(I'm upgrade to stretch, but revert to jessie).

  2. What ppa support 7.x release for jessie ?

Vim and YCM are prone to suffer from these many portability problems because of its buddy: python, which is just nightmare for user deploy. As you see, you're missing python2 in vim8 and reverted but didn't tell us any actual meaningful information you have found. On jessie you want YCM working as it was used to work, you should just stick to the hash commit version that worked if you're not willing to solve the tip of master issue for your system. YCM with semver would be meaningless for you because your system isn't being covered in tests, and hence, would still be prone to breakage.

Most plugin managers support hash commits just like they support tags.

vim-plug: "branch/tag/commit support".

Commit hash is the most stable option you can have in a frozen system.

oblitum commented 7 years ago

Versioning is useless for this but I don't mean it's useless in general. It's useful for having official and third-party precompiled release packages, which would be great.

oblitum commented 7 years ago

To give you an actual example of equivalent situation. Clang 4.0.0 from ArchLinux repositories works on real x64 ArchLinux machines and doesn't currently work on ArchLinux under WSL. Having a version and an official ArchLinux package published didn't help in making it work on an untested/unsupported system.

Valloric commented 7 years ago

This thread isn't going anywhere so I'm locking it.

@vasyapupkin123456 You got a good summary from @puremourning: master is our stable branch.

Valloric commented 7 years ago

@vasyapupkin123456 Also, your demeanor in this thread shows disregard for our Code of Conduct. You have been banned.

oblitum commented 7 years ago

@Valloric I'd like to be removed as Collaborator (not meaning that I won't look for contributing later).

Valloric commented 7 years ago

@oblitum Done! Feel free to ping me if you'd like to come back to us at some point when you have more time. :)