Release plans ?

[vladak]

Are there any plans to do a (stable) release ?

[masatake]

Could you see "Milestones" menu?
It is just my plan.

[vladak]

Yes, I see couple of versions there. Any concrete timelines ?

[masatake]

I would like to release a stable version than can be included in GNU/Linux distro with 2016. However, I cannot promise it as usual.

[hauleth]

Could we have some pre-release versions tagged on GitHub? It would make life so much easier for almost everyone who want to introduce Universal Ctags as a package.

[hauleth]

Ping?

[masatake]

I think it is far from releasing.

[hauleth]

@masatake I am not talking about full 1.0.0 release, but tagged versions like 0.0.1 (SemVer mention that anything that is 0.x.y is meant to be highly unstable) which would help with creating development packages for various package managers. This would also help with generating version as git describe would return current version in quite nice format.

[masatake]

Do you really need a tagged version?

#1272

[AMDmi3]

Yes, we do really need a tagged version, otherwise there's a mess with versions and no way to know if the package is up to date.

https://repology.org/metapackage/ctags/information

So pretty please, do tag regular release versions.

[emptyflask]

Homebrew requires tagged releases, and once universal-ctags is included in the core list, it can be used with other packages like GNU Global...

[masatake]

We are working hard for releasing.

The reason I don't do tagging is I want "standard users" not to use broken version of universal-ctags.
Here "standard users" mean people who just use "binary" executable getting via a package system or something. I myself such a people about other software than ctags, I don't want to make them unhappy.

[cweagans]

@masatake I think people generally know that if it's a 0.x release, there will be some rough edges. I would really like to encourage you to regularly tag 0.x releases until universal ctags is to a point where you think "normal" users will be happy. This will really help with getting packaging taken care of before the 1.0.0 release.

[hauleth]

Excerpt from Server specification:

Major version zero (0.y.z) is for initial development. Anything may change at any time. The public API should not be considered stable.

[anthraxx]

@masatake how about an xmas present in form of a release? 😋

[masatake]

Sorry, but we have to do two things: stabilizing the file format called tags format v3 and writing its document. I thought I had much time for working on these topics in this fall. However, I could not find much time. The next Easter is the target.

[hauleth]

We aren’t talking about version 1.0 but about 0.0.1-alpha.1.pre right now.

…

-- Łukasz Jan Niemier

Wiadomość napisana przez Masatake YAMATO ***@***.***> w dniu 17.12.2017, o godz. 03:42: Sorry, but we have to do two things: stabilizing the file format called tags format v3 and writing its document. I thought I had much time for working on these topics in this fall. However, I could not find much time. The next Easter is the target. — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[cweagans]

@masatake Whether you tag a release or not, the fact is that people are using universal ctags right now because it's already way better than exuberant ctags. I understand if you don't have the time or interest in maintaining these releases, but is that something you can delegate? I'm willing to step in and do some limited support for 0.x releases to help offload some of the maintenance burden.

Please consider taking a page out of Neovim's book: they are releasing 0.x releases as they continue to improve the vim codebase. There is no expectation of backward compatibility in these releases, but they are extraordinarily useful for packaging, testing, daily use, etc.

[masatake]

Thank you for your proposal.

What I'm afraid of is getting many bug reports. We changed the default file format. It may have a big impact.
I think we cannot respond to the bug reports well because even I don't know well about the new file format.

• introducing version 3 format,
  • making --format=3 as the alias for --output-format=u-ctags.
  • [rintiing TAG_FILE_FORMAT 3 when the options are give.
• update readtags to handle TAG_FILE_FORMAT 3, and
• documentation for the format

are needed.
Much of things are done in a pull request submitted by @b4n.

[cweagans]

What I'm afraid of is getting many bug reports.

Just for the record, I think it's totally okay to just close those with a canned response about 0.x backward compatibility not being supported. The answer is simply "Regenerate your tags file using the new format."

I will happily and ruthlessly close those bug reports if it means there's a tagged release to work off of.

[masatake]

Just for the record, I think it's totally okay to just close those with a canned response about 0.x backward compatibility not being supported. The answer is simply "Regenerate your tags file using the new format."

You don't understand the point. ctags is a just backend tool. The new format we are testing introduces backslash for escaping. As the result, client tools(==frontend tools) will not work expectedly. Regenerating
tags in the feature doesn't solve the issue. Rewriting or updating the tools are needed.

I can image users get angry with me for such format change. The people may say "compatibility" is the most important. If I am an user, I also think so. So I'm trying "breaking compatiblity once, but only once when releasing 6.0." (if possible).

[masatake]

Anyway I will work on the format 3 issue. I must stop hacking fortran parser. It is written well.

[cweagans]

If you're strongly opposed to this, I'm probably not going to change your mind here. However, even if tooling needs to be updated to work with the new format, a pre-release would help the tooling maintainers accomplish that task.

The worst possible scenario here is that 6.0 is tagged and none of the tooling is updated. That would be really, really bad. The best case scenario is that lots of users try the pre-release and find legit bugs (not related to the tag format), get tooling updated, etc, and then the 6.0 release is an awesome success with associated tooling working perfectly on day 0.

I know what I would pick, but then again, I guess I'm not the maintainer here.

[masatake]

@k-takata, how do you run the script?
Is it possible to run the script here, the main ctags repository?

To be honest, I'm also waiting for a release.

If we run the script here, and the script puts tags, can I say I provide the releases that you want?

[k-takata]

ctags-win32 uses AppVeyor's cron to run the script.
GitHub Actions also supports scheduled builds.

If we run the script here, and the script puts tags, can I say I provide the releases that you want?

Hmm, we should carefully consider the versioning rule.
I prefer semver. E.g. v6.0.0-alpha-YYYYMMDD.

However, I know a project that doesn't follow semver: https://github.com/google/re2
They use the YYYY-MM-DD style and create a tag once a month.

[codebrainz]

Github also has "releases" feature as @ploxiln uses in their fork, it takes like 30 seconds to make a "release". The form looks like this:

You can use the "This is a pre-release" to signify to people that it's not a stable release. If you put the next version number in the form, it will make the Git tag automatically. You also don't have to add build artifacts since it will automatically create a zip/tarball from the repo, though it might be useful to provide a make dist tarball so people don't need Autotools and stuff to build with it.

[masatake]

@k-takata, thank you for responding.

Supporting semver in this stage is hard.

In the summary of semver:

MAJOR version when you make incompatible API changes,

This means I have to manage MAJOR version carefully.
People say just tagging is enough. semver is more than just tagging.

My idea is v5.9.YYYYMMDD. I don't want to take care of API changes when tagging.

@codebrainz, thank you for your input. However, I don't want to make an archive.
If the Geany development process needs it, I will make it. What I should do is merge the parsers in the pull request from Geany project.

[ploxiln]

My idea is v5.9.YYYYMMDD. I don't want to take care of API changes when tagging.

@codebrainz, thank you for your input. However, I don't want to make an archive.

Fair, and appreciated, thanks.

[codebrainz]

@codebrainz, thank you for your input. However, I don't want to make an archive.
If the Geany development process needs it, I will make it. What I should do is merge the parsers in the pull request from Geany project.

I wasn't really speaking as a Geany developer, I was just giving a suggestion/info on a simple way to make people who want a "release" happy now without burdening you too much, by just using the built-in Github "release" mechanism to cut a release.

I'm not versioning expert or package maintainer, but it seems kind of pointless to auto-generate tags/releases for the purpose of this Issue since the tags/releases are as arbitrary as just using Git SHAs of a commit and everyone will be using different auto-tagged versions.

[masatake]

I wasn't really speaking as a Geany developer, I was just giving a suggestion/info on a simple way to make people who want a "release" happy now without burdening you too much, by just using the built-in Github "release" mechanism to cut a release.

I see. Thank you.

[ploxiln]

As a small complication, I would like for ctags --version output to correspond to the git version tag ... and this version ends up in lots of test output unfortunately ... so ideally there is a little bit more to it than just an automated git tag. But anyway, I'll take whatever I can get, even just a git tag is better than nothing :)

(for a quick overview of everywhere the version appears, you can take a look at b599093...ploxiln:9363e33)

[masatake]

As a small complication,

Understandable. But I focus only on tagging at this time.

@k-takata, is the naming scheme for tagging "v5.9.YYYYMMDD" acceptable?

[docwhat]

Semver may be better thought of as BREAKING, FEATURE, FIX instead of MAJOR, MINOR, PATCH.

I don't have much experience, but is detecting BREAKING changes hard when writing a commit?

That being said, I'm a beggar here and not a chooser.

Even a regular date-stamp style tag is better than nothing. As long as a human or computer can tell which is newer.

[k-takata]

That might be acceptable even it doesn't follow semver strictly.
Are you thinking of tagging automatically or manually?

[masatake]

@docwhat, I know semver is much better. However, in 5.9.x series, I will not choose the semver scheme.
From 6.x, I will choose the scheme, however, I cannot imagine when 6.x is available.
I wrote various reasons I don't make a release. I will add one here.

I found there are two levels in ctags about semver.

• the main part level

  the command line interface like --regex-, --list-kinds, ... are included here.
  Most of my work in this project is about the main part.
  As @docwhat wrote, I recognize I'm dong "BREAKING" or not.
  Therefore I use "[SELF-INCOMPATIBLE]" in the commit log. It implies the need of a major version
  up in the semver meaning. About the main part, it is possible to take the semver scheme.

• the parsers' part level

  A parser defines kinds, fields, and extras. I would like to avoid BREAKING however, I made and I accepted
  BREAKING. I think I have to introduce more breaking especially about Making reference tags for external entities instead of definitions tags #2428.
  I wonder such breaking in a parser level needs incrementing MAJOR or not.
  Consider you are a C programmer. If we introduce a "BREAKING" change in our COBOL parser,
  do you think u-ctags introduces a "BREAKING" change? I guess you don't care.

I think the semver should be applied to u-ctags in the above two levels separately.
So when referring a version of u-ctags, you (a C progammer) may say:

u-ctags-6.2.1 + c-parser-1.2.0

A coble programmer may say

u-ctags-6.2.1 + cobol-parser-1.0.3

I wonder how to represent this situation in the semver naming scheme.

[masatake]

@k-takata, I'm thinking about automatically.
And as usual, I need your help.
Can I ask you to do the similar as you did in ctags-win32?

[polyzen]

For handling of the date part of the version, this could provide insight:
https://calver.org/

[docwhat]

If you are building a package made of parts with language parsers and a core engine then you would have a version number for each parser (e.g. cobol-parser 1.0.3), a version for the core engine (core-engine 6.2.1) and then a "combined" package number: u-ctags 6.3.0

If any parser or the engine bump a major number, then the combined package would bump its major number too.

Yes, that means that the combined package may reach triple digits quickly, but that's okay. The version numbers are just numbers.

Alternatively, you can manage the combined package version entirely as "marketing" ... e.g. with a date only (via calver.org schemes)

Both are legit.

[masatake]

I will implement weekly-automatic-tagging v5.9.YYYYMMDD.0 as trial.
I appended ".0" at the end for allowing us to release an extra version manually.

[masatake]

See #2655.

[masatake]

The initial tag, p5.9.20201011.0, was created.

[polyzen]

Does the p at the beginning of the version have any meaning?

Edit: Seems it denotes "periodical":

ctags/misc/git-tag-maybe.sh

Lines 8 to 18 in e9baeff

	if desc=$(git describe --tags --exact-match); then
	case "${desc}" in
	p*.0)
	echo "do nothing because nothing happens since last tagging"
	exit 0
	;;
	*)
	echo "found a tag but it is not periodical one; create a periodical tag"
	;;
	esac
	fi

[masatake]

Edit: Seems it denotes "periodical"?

Maybe yes. I cannot remember the meaning. I was looking for a character other than 'v'.

[masatake]

I'm thinking about releasing 6.0. I put "ctags6" label in our issues and pull requests.