Post a Release of Current FM12 App

[joewheaton]

Hey Weber, Zip up the database (I think it is here) and post it as a Release. I would suggest tagging it with something indicative of Beta (e.g. 0.1).... I would reserve 1.0 for when we launch the proper LTPBR commercial grade PWA app. Make sense?

[nick4rivers]

@joewheaton and @philipbaileynar I can post a release. But, this isn't a good place for people to download the filemaker application file, or the database. It seems like a release has to include all the files we are tracking in the REPO - which is primary just the files used to build the static site.

Question: Is there a good way to add file downloads to a jekyll site? Ideas? Thanks.

[philipbaileynar]

It's not best practice to put binary files in repos.

@nick4rivers can you explain people obtain the File Maker Pro app? How would a new user get up and running?

This repo should really only have the following:

• Documentation web site
• License file with license agreement
• readme.md with brief pointers what this repo is and where to get stuff
• Any pre or post processing scripts for getting data in, out, analysis or reporting etc.
• schema definition files. I don't know if this is relevant for File Maker Go, especially a database that is predominantly made up of user interface forms. But in most database technologies its possible to export the entire database definition to text files. (e.g. here's the BRAT sqlite DB definition). Like I said, I don't know how to do this with File Maker Pro. Attaching an empty copy of the database to a GitHub release as @joewheaton suggested is not a bad strategy, but that's kinda useless if GitHub is not the place people come to to download the latest app. Regardless, there has to be a place where each release is zipped and stored as a backup.

[nick4rivers]

@philipbaileynar yes, I agree, the .fmp12 file has no business here on Git. It really will just be for the site.

I just need a stable bit of storage to allow people to download a blank copy of the db and the protocol document. It can be google drive for all I care. If you have ideas let me know - otherwise I'm going to just check this issue off.

Thanks Philip!

[philipbaileynar]

@nick4rivers what I'm about to say might seem like a contradiction to my last comment...

If you are looking for a place to store and disseminate the blank copy then "GitHub Releases" is a good pattern to use.

1. Click on the Code tab of this repo.
2. Click on the Releases sub-tab. There are none so far, so click create new release.
3. Give the release a tag number. Remember, three digits separated by periods. NO SPACES.
4. Give the release a title (I usually just reuse the tag name for clarity).
5. Type a description if necessary. Even if it's an informal reminder to you!
6. Here's the important part. Drag and drop the blank copy of the database to the "Attach Files..." section below the description.
7. Click Publish Release.

Now in the web site you can use a link like the following. Note how it says "latest" instead of the specific version number of the release that you just created. This is super convenient because it allows you to have a permanent URL that always takes users to the latest release. Here is the equivalent link that we use for RAVE:

https://github.com/Riverscapes/RaveAddIn/releases/latest

And here it is in use on the RAVE home screen in the orange button.

What this gives you is a really nice linear trail of your releases, each with a clear version number, all without bloating your repo with binary files.

Shout if you want to walk through together.

[nick4rivers]

Yes, @philipbaileynar , thanks - I think this actually will work perfectly. Thanks a ton.