Bower Version Update and Naming Issue

[AlJohri]

bower install twitter-bootstrap-sass

currently downloads Bootstrap 2. Is there any chance you can update this to the most recent version of Bootstrap?

Also,

bower install bootstrap-sass

or

bower install sass-bootstrap

currently links to https://github.com/jlong/sass-bootstrap

Any way to fix the naming issue and claim "bootstrap-sass" as is the name of this repository?

[glebm]

Do we even have a bower version? I don't think so. PR welcome

[ghost]

@AlJohri : that project is managed by jlong just as it says not by this group of folks

[AlJohri]

@jrobeson, @glebm "twitter-bootstrap-sass" links to THIS repository.

This can be verified here: http://sindresorhus.com/bower-components/#!/search/twitter-bootstrap-sass (takes a second to load) or view the output of bower info below:

➜  ~  bower info twitter-bootstrap-sass
bower twitter-bootstrap-sass#*  cached git://github.com/thomas-mcdonald/bootstrap-sass.git#2.0.3
bower twitter-bootstrap-sass#*  validate 2.0.3 against git://github.com/thomas-mcdonald/bootstrap-sass.git#*

{
  name: 'twitter-bootstrap-sass',
  homepage: 'https://github.com/thomas-mcdonald/bootstrap-sass',
  version: '2.0.3'
}

There must be a valid manifest JSON (bower.json I presume) in the current working directory according to http://bower.io/#registering-packages so I'm confused as to how this currently exists.

All renaming of bower packages is done in this github issue: bower/bower#120

➜  ~  bower search bootstrap | grep jlong
    sass-bootstrap git://github.com/jlong/sass-bootstrap.git
    bootstrap-sass git://github.com/jlong/sass-twitter-bootstrap
➜  ~  bower search bootstrap | grep thomas
    twitter-bootstrap-sass git://github.com/thomas-mcdonald/bootstrap-sass.git

The "bootstrap-sass" package points to a renamed github repo by jlong. I can request to deregister this package and redirect to this version with your permission!

[ghost]

the opposite naming of bootstrap-sass vs sass-bootstrap is why i thought so.

[glebm]

Hi @AlJohri! It would be great if you add a valid bower.json file to this repo! bootstrap-sass only works with ruby for now, but that should change soon #473

[jasonschock]

@AlJohri @glebm Bower is actually looking at this repo's tags to generate the available version numbers. Unfortunately, when the tags changed to add an additional dot-number, i.e. the vN.N.N.N format rather than vN.N.N, it broke the way Bower parses them. So v2.0.3 is the last available version that Bower sees.

The ideal fix would be to simply change the version tags to something semver, which is what Bower prefers. Then you wouldn't even need a manifest file. It would just work.

[glebm]

Changing the versioning format is not really an option (need both upstream version and ours; rubygems doesn't support + version metadata; there are tens thousands of users with ~> locked dependencies). What's the second best fix?

[jasonschock]

Good points, and good question. What about a new, additional tag that follows semver, but is intended only for Bower consumption? E.g. something like v3.0.2-bower. Perhaps v3.0.2-bower.1, v3.0.2-bower.2 to capture that last .N somehow. (The importance [and formatting] of that is debatable, IMO.)

It's also worth noting that a user can just force-install a specific tag/SHA like so:

bower install '<git-url>#<git-tag-or-sha>'

(This solved the issue for me.)

I think it's a question for @glebm, et. all, how important Bower support is vs. the extra effort it will take to implement an additional tagging scheme and/or create & maintain a package file.

[glebm]

@jasonschock Bower support is important, we can mention bower install '<git-url>#<git-tag-or-sha>' in the readme and set the version in bower.json. This package is going to move to twbs/boostrap-sass (ed tom) soon, that's when we can change the bower registry.

[glebm]

This issue depends on #481

[glebm]

@jasonschock @AlJohri @jrobeson Could you guys look at #488 and comment if it's OK

[glebm]

It appears there is no solution to compatible version numbers short of fixing SemVer itself. I found the relevant SemVer issue and outlined the problem there: semver/semver#168

[thomas-mcdonald]

I don't really know if it's 'fixing' semver, given we're not following it. I think @mdo wants us to move to being pegged to upstream's releases, which is fine, we could retain the .z for Rubygems though?

[glebm]

We have switched to v3.1.0 scheme for all non-rubygems versions as of now!