Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Deal better with stable and pre-release package versions #63

Closed
daveverwer opened this issue Aug 12, 2019 · 7 comments
Closed

Deal better with stable and pre-release package versions #63

daveverwer opened this issue Aug 12, 2019 · 7 comments
Labels
enhancement New feature or request

Comments

@daveverwer
Copy link
Member

Inspired by this conversation.

When building out the site I specifically looked at what Xcode will import if you paste in a git repository. It picks the latest, stable version of a package. For example, even though Alamofire has a 5.0.0-beta.7 release right now, Xcode shows 4.8.2 when importing it. I chose to match that with the site.

As you can see in the Twitter thread, that's not perfect.

@daveverwer
Copy link
Member Author

Also transferring this comment from @jshier:

I'll report this as feedback as well, Xcode should really show you both too. Reported as FB6961625.

@daveverwer daveverwer added the enhancement New feature or request label Aug 12, 2019
@daveverwer
Copy link
Member Author

daveverwer commented Aug 14, 2019

I've done some work on this today and I am now scraping both beta versions and stable versions from the git repository. The big question now comes down to how to best display it all.

There are four cases to consider:

  1. Where none of the tags in the git repository are valid semantic versions.
  2. Where the latest tagged semantic version is also the latest version of the package.
  3. Where the package has never had a stable release, only beta releases.
  4. Where the latest semantic version is a beta, but there is also a stable version.

I think the answers to the first two cases are fairly obvious, and the last two are less so.

Where none of the tags in the git repository are valid semantic versions

I think this is obvious, and it should look just like it does right now with no version displayed. Like this:

Screenshot 2019-08-14 at 19 57 47

Where the latest tagged semantic version is also the latest version of the package.

I think this is also fairly obvious, and it should look just like it does right now. Like this:

Screenshot 2019-08-14 at 19 56 27

Where the package has never had a stable release, only beta releases.

This is where things get a little bit interesting. In this situation we are dealing with repositories that have no stable versions at all. So, the only tags that are valid semantic versions have pre tags.

Xcode always selects the latest stable version when adding a package, so there's an argument to have some kind of visual difference to this in the search results. Maybe something like this?

Screenshot 2019-08-14 at 20 04 24

It could be something else, but dimming the version number is an idea.

Where the latest semantic version is a beta, but there is also a stable version.

This is where things get really interesting. When there is a package that has in the past had a stable version, but that is now under development of a beta version.

When there is any stable version, Xcode will recommend and default to that version when you use it to add the package. You have to manually type in the beta version number if you want it.

Maybe it should look something like this?

Screenshot 2019-08-14 at 20 06 34

I have all of the server side logic already implemented and this screenshot is actually from my local development version of the site, but I'd really love some opinions before deploying it.

Thanks!

@jshier
Copy link

jshier commented Aug 14, 2019

One important thing to keep in mind is that the latest and stable versions, whatever they may be, may also have different minimum OS and Swift levels. For instance, Alamofire 4 still supports iOS 8+ and Swift 3.2+, which is far lower than Alamofire 5. So it seems that, if those are different (however you're detecting that), that all information from both should be displayed. In that case, perhaps vertical display would be better?

@daveverwer
Copy link
Member Author

daveverwer commented Aug 14, 2019

One important thing to keep in mind is that the latest and stable versions, whatever they may be, may also have different minimum OS and Swift levels.

Yes, but there are a couple of problems with this. First, I have yet to implement per version metadata 😀 It's on the list but it's not yet implemented.

Second, these search results are already getting really visually busy. I'm not sure I can get all of that metadata to be displayed in a visually clear way.

@jshier
Copy link

jshier commented Aug 14, 2019

Then I think I like the last UI, as at least then it could be somewhat clear the metadata is for the latest version and not the stable one, but there will likely always be confusion. Perhaps being able to select between the two?

@cmtrounce
Copy link
Contributor

The last UI is the best, and I think it provides the most useful information. By that point, people searching will have enough information about what the library does to make a judgment on whether to click through to the details page.

@daveverwer
Copy link
Member Author

This is what I went with in the end:

If there is no version tag that is a semantic version:

Screenshot 2019-08-15 at 10 52 57

If the latest version is stable, or if there is only a beta version and no stable version has ever been released:

Screenshot 2019-08-15 at 10 56 16

If there is a beta version, but a stable version has been previously released:

Screenshot 2019-08-15 at 10 55 59

The metadata below the version is from the latest commit on the default branch right now, but that's next on my list. I also came up with a way to make the search results look good with two sets of metadata so your wish may come true @jshier!

This is now live on the site.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants