Jitpack.io: Using both non v and v version of git tags

[codvio]

According to semver 1.0.0 git repos must use v prefix for tags.

• http://semver.org/spec/v1.0.0.html#tagging-specification-semvertag

It is removed in version 2 but almost all projects and even semver's itself use v prefix as shown in the URL.

• http://semver.org/spec/v2.0.0.html

Projects use v prefix in git tagging but not in maven repos. For instance this is 1.3.2.RELEASE version of spring-boot project:

• https://github.com/spring-projects/spring-boot/tree/v1.3.2.RELEASE

But you should request non-v version the project:

• http://repo1.maven.org/maven2/org/springframework/boot/spring-boot/1.3.2.RELEASE/

In current jetpack.io version we must use the v version of the project.

Central Repo Version:

compile 'org.springframework.boot:spring-boot:1.3.2.RELEASE'

JitPack Version:

compile 'com.github.spring-projects.spring-boot:spring-boot:v1.3.2.RELEASE'

If jitpack can support both v and non-v versions of the projects it can be good.

For instance both lines should be welcome:

compile 'com.github.spring-projects.spring-boot:spring-boot:v1.3.2.RELEASE'
compile 'com.github.spring-projects.spring-boot:spring-boot:1.3.2.RELEASE'

[jitpack-io]

Thank you for the suggestion! In a lot of ways it makes sense but there can be downsides as well:

• First of all it's possible to add two tags - one with v and one without on different commits.
• If JitPack supports both then its also more confusion for the user - which one should I use?
• Or when users report bugs you have to try to reproduce it on two versions.

So would recommend using tags without the v because it's non-ambiguous.

On the other hand, a lot of projects already use the v. Perhaps JitPack should always use a version without the v. When there's only one way to do things then it is simpler and less confusing for everyone.

[codvio]

This is the possible pseudo JS code for suggestion, code is the best way to explain something to developers :)

function fetchVersion(versionName) {

   if (existInGithub(versionName)) {
      return buildAndDeploy(vesionName, versionName);
   } else if (existInGithub('v' + versionName) {
      return buildAndDeploy('v' + vesionName, versionName);
   }

   return null;
}

[jitpack-io]

Sure, but the current logic is simpler

function fetchVersion(versionName) {
    if (existInGithub(versionName))
        return buildAndDeploy(versionName);
    return null;
}

so its easier to explain.

[raniejade]

I think you should re-consider this, to be consistent with other libraries deployed in central. Most versions in central don't have a v prefix, the only time this is present is on a git tag.

[jitpack-io]

@raniejade Agreed, most existing libs don't use the v in versions but is that good enough reason to support it considering issues mentioned earlier?
One argument could be that users will intuitively try to specify a version without the v and that will fail.

[raniejade]

• First of all it's possible to add two tags - one with v and one without on different commits.

You could enforce it at build time, if a tag looks the same with a previously built one fail the build.

• If JitPack supports both then its also more confusion for the user - which one should I use?

I don't see any confusion here. People who uses central a lot will intuitively use a version without v (a lot of them uses semantic versioning).

• Or when users report bugs you have to try to reproduce it on two versions.

How often does that happen? It's the publishers responsibility to ensure that there are no duplicate tags.

[gdejohn]

What if JitPack used the name of a GitHub release for the version instead of using the tag? The API provides both. So the tag can be v1.0 to match the git convention, and you do a GitHub release for that tag and name the release 1.0 to match the Maven convention, and JitPack uses the release name.

[jitpack-io]

Ok, versions without 'v' prefix should now be working too

[gdejohn]

@jitpack-io, a minor drawback with this approach is that when you go to the JitPack page for a project, the first thing you see is the versions listed under the Releases tab, and they correspond to the tags. So for anyone using a dependency from JitPack and omitting the v prefix, if the project follows the git tagging convention, it appears to be inconsistent. (I can imagine people wondering, "Wait, that works? Why does that work?")

Have you given any more thought to my proposal?

What if JitPack used the name of a GitHub release for the version instead of using the tag? The API provides both. So the tag can be v1.0 to match the git convention, and you do a GitHub release for that tag and name the release 1.0 to match the Maven convention, and JitPack uses the release name.

Presumably it should only apply to new releases. Perhaps it should require setting a flag in the jitpack.yml config file?

[jitpack-io]

Hi @gdejohn ,
Agree that it should only apply to new releases. We still need to figure out how to deal with GitHub API rate limits. We'll quickly exceed if we query releases API or if we check jitpack.yml