"Bleeding edge" link the the front-facing README is confusing

[Robert Leach]

USE CASE: WHAT DO YOU WANT TO DO?

Get the latest (possibly unstable) release.

STEPS TO REPRODUCE AN ISSUE (OR TRIGGER A NEW FEATURE)

1. Go to the main TreeView page.
2. Click the "Bleeding edge" link under the download section
3. Look for a download link for the latest bleeding edge version

CURRENT BEHAVIOR

The bleeding edge "page" does not have a link named "download", nor does it describe what is being downloaded as the latest build. The link which performs a download (presumably of the "bleeding edge version" is named "view raw", which does not in any way suggest what it is the user will get when clicked.

EXPECTED BEHAVIOR

Either the "bleeding edge" link in the readme should go to an automatically generated page of builds, aptly named and dated, or it should just skip the intermediate page and download the latest version.

DEVELOPERS ONLY SECTION

SUGGESTED CHANGE (Pseudocode optional)

none

FILES AFFECTED (where the changes will be implemented) - developers only

README

LEVEL OF EFFORT - developers only

trivial

COMMENTS

This is the bleeding edge link:

https://bitbucket.org/TreeView3Dev/treeview3/src/37cf1e6b59426a56183f80d8dc136819eb99854f/build/libs/treeview3-all-267ff8e.jar?at=master

[Anastasia Baryshnikova]

I noticed that too. I think the "Bleeding edge" link on the home page is redundant with the sentence right below it. I would remove it and just leave:

More recent "bleeding edge" releases, as well as older stable versions, are available at the Treeview Wiki page.

On the Wiki page, there's a section for the bleeding edge release, which should contain the link to the latest automatically generated JAR file (issue #464 that @TreeView3Dev is working on). I think it should only be 1 link or the last 5 max (if that's possible to automate).

[Christopher Keil]

I have removed it, the link doesn't work anyways if the built JAR on master is updated. We need to figure out a better automated way than including the build/ folder in the repo and linking that. Maybe the new Bitbucket pipelines can help, or we consistently update the Wiki page on a weekly basis.

[Robert Leach]

I thought that the pipeline feature was eventually going to be behind a pay wall.

[Christopher Keil]

If that is really the case then we need to figure something out. I haven't yet researched an automated way, ideally using Gradle. Another (temporary?) option could be to manually update a bleeding edge list (5 or so entries) on the Wiki page once a week with a build from master.

[Anastasia Baryshnikova]

I think we should go with the pipelines for the time being and not worry about the pay wall. If the problem arises, we'll figure it out then (e.g., pay for the feature, if it's really useful to us -- it looks like it may be quite cool, if it works).

[Robert Leach]

Lance had suggested using Jenkins or some other tool whose name is escaping me at the moment. Does it start with a "J"?

[Robert Leach]

The other suggestion was Travis. Another potential option is GitLab.

Lance and I just attended a Jenkins class yesterday.

[Christopher Keil]

I really like GitLab to be honest.

[Robert Leach]

Ok. Looks like as academic users, it will be free with up to 500 build minutes. Not sure how that affects us. Free trial ends early 2017.

https://confluence.atlassian.com/bitbucket/future-bitbucket-cloud-pricing-plans-856694492.html

[Anastasia Baryshnikova]

Closing this issue as resolved (the link has been fixed). I'll add a new issue to deal with the automatic generation of JAR/APP files.

[Robert Leach]

In master