Making a "release"

[masatake]

This issue is for tracking general issue for releasing .tar.gz.

I need at least one volunteer helping me updating ctags.1. If you are interested in, talk to me, here.
If I cannot find any volunteer, I will not make a release.

[masatake]

The first of all, I would like to decide the version number: 6.0 or 1.0.
(See #354)

If we choose 6.0, we can use 5.99.n as number for beta version.
If we choose 1.0, we can use 0.99.n as number for beta version.

I prefer 6.0 but I don't have strong opinion.

[cweagans]

My thoughts:

• Use semver
• Start at 1.0, as this project is not Exuberant Ctags (other projects have done it this way. Neovim just tagged 0.1.0, while vim is at 7.3 I think)
• I could possibly be interested in updating ctags.1, but for clarity and transparency, can you detail what needs done?
• If this project is going to be around long term, I think we need to get serious about creating real supported releases regularly. If it's not 100% ready for whatever reason, then let's do a 0.1.0 release or something, but let's at least get something out there.
• For packaging and distribution on different platforms, here is a possible solution:
  • Linux distros: OpenSuse's OpenBuildService handles all of these really really well. We can start with Fedora and Debian (and possibly a separate one for Ubuntu specifically), and then start rolling out support for other distros later.
  • Windows: Appveyor is free for open source projects
  • Mac: We already have the Homebrew packaging stuff, but it would be nice to provide "bottles" for the formula, which is essentially a pre-built formula (see official docs for more info). We only need to do this manually if we continue maintaining our own Homebrew tap. If we can get a 1.0 release out the door, we can add the formula to the main Homebrew formula repository, and we'll automatically get pre-built binaries on 4 different versions of Mac OS. For now, though, I can provide pre-built binaries for Homebrew on the most recent release (El Capitan)
  • When a release is tagged on Github, a .tar.gz and a .zip source package will automatically be built. I think it would make a lot of sense to grab the packages from the various build services and associate them directly with the Release in Github (so that all of the binary, OS-specific packages show up in the release file list). That doesn't have to happen right away, however. I'd be happy enough just providing links to users for the right place to download things.

[liugang]

There are too many ctags, is it possible to have universal-ctags with other binary name?

$ update-alternatives --list ctags
/usr/bin/ctags-exuberant
/usr/bin/ctags.emacs24

$ dpkg -L emacs24-bin-common|grep ctags
/usr/bin/ctags.emacs24

$ dpkg -L exuberant-ctags|grep ctags
/usr/bin/ctags-exuberant

example:

universal-ctags-1.0.tar.xz with binary /usr/bin/uctags ?

[viccuad]

Hi, I'm packaging universal-ctags for Debian (in fact, the package is done since some weeks, and I'm just waiting for #92 to be fixed).

About using OpenSuse's OpenBuildService for providing a Debian package, it seems fine if you want to release a .deb as upstream, but for having it inside the Debian repos it seems more appropiate to package ir properly: to comply with Debian's Policy, be up-to-date on changes on the dependencies of the distro, and make use of some distro goodies, such as reproducible builds (as I have packaged it, it should be already reproducible) or:

@liugang , I don't know about other distros, but in Debian I have packaged it as universal-ctags, and the binary has as name ctags-universal using the provided configure flag '--program-transform-name'. Anyways, it shouldn't be a problem since in Debian you can choose from all ctags installed in the system, because we provide a chooser: update-alternatives.

[cweagans]

I would prefer that the binary name remain as ctags, and have this package conflict with exuberant-ctags.

The major benefit that I see about using OBS is that we can tag a release, kick off a new build, and the update is available immediately. How does that process work for Debian? Do we just wait for you or somebody else to update it?

[vhda]

@cweagans in Debian the correct way is to have different binary names per package, but all being configured as a "ctags" provider. By default Debian uses a priority list to choose which "ctags" provider will be used, but the administrator can configure it manually also if necessary.
This allows having multiple packages that provide the same binary (like bash and dash for /bin/sh) to coexist in the same environment.

@viccuad would you be willing to create a PR (at the time you find appropriate) to have the debian folder merged into our repository?

[cweagans]

@vhda I see. So if somebody installs universal-ctags, and there are no other ctags providers, they'd still be able to just run ctags from their shell and ctags-universal would be the one that gets executed?

[vhda]

@cweagans exactly!

Another example, which requires more steps than only configuring the alternatives, is having radeon and fglrx AMD graphic drivers installed at the same time in the same machine. The GLX library is provided by both Mesa and fglrx packages, with the later being the default. Nevertheless, the administrator can choose to use Mesa instead.

[cweagans]

Okay, that works perfect. debian++ I knew there was a reason I liked that distro

What does the update process for an official debian package look like?

1. We tag the release on Github
2. ?
3. Profit! Users can upgrade with apt

Just wondering what step 2 consists of.

[vhda]

For that part @viccuad will need to step in.
You can read this to get more information: https://wiki.debian.org/NewQueue
And search for more hits in google regarding Debian's New Queue.

[cweagans]

I created a bunch of other smaller, more focused issues. Please see https://github.com/universal-ctags/ctags/milestones/Initial%20release for the full list, and #655 for the Debian packaging discussion.

[cweagans]

Okie dokie. I think I'm done categorizing things now. https://github.com/universal-ctags/ctags/milestones/Initial%20release should be up to date. We're already 54% of the way to an initial release (since I also recategorized some of the already-closed issues)!

@universal-ctags/admins @universal-ctags/developers Please let me know where else I can help, particularly around coordination, documentation, and packaging.

[masatake]

(I got a trouble in my health.
I will catch up.)

[mcritchlow]

Just wanted to 👍 this effort. Having a tagged version is the only blocker for me packaging this up for the distro/package manager I use.