Remove package_damellis_attiny_index.json from repository.

[mrbbp]

On Arduino 1.6.4
https://raw.githubusercontent.com/damellis/attiny/ide-1.6.x-boards-manager/package_damellis_attiny_index.json

in the Board manager, when try to install bord have the following error
"CRC does not match! File is corrupted"

unable to install

[per1234]

The checksum has changed since I made that .json file. It was probably caused by Github recompressing the file.

@mrbbp You can use this temporary Boards Manager install URL to install attiny 1.0.1:
https://raw.githubusercontent.com/per1234/attiny/temp-json/package_damellis_attiny_index.json
I have not checked v1.0.0 so it is likely the CRC will not match on that version. We will figure out a permanent solution to this problem soon and post the new URL here at that time. *Edit: damellis has fixed the .json file so you can now use the link you posted above.

@damellis I think this indicates that the current strategy of using the zip files automatically created by Github will not work. I can think of a few alternatives:

1. Manually create the install files and add them to the ide-1.6.x-boards-manager branch. This is the way Sparkfun did theirs.
2. Use a gh-pages branch that will only contain the json file and the zip files. This is how Adafruit has theirs set up. The advantage is that the URL would be shorter(damellis.github.io/attiny/package_damellis_attiny_index.json). This option would require you to create the gh-pages branch.
3. Use github releases. This is how Sanguino has it set up.. This option would require you to create the releases and add the install files.

I'd be happy to work on the fix and submit a pull request, just let me know what you want to do.

[damellis]

I updated the checksums as a temporary fix.

per1234: thanks for the run-down of options. I don't like (1) as it seems weird to have the zip file in the repository itself. Given that these basically are releases, it seems like it would be nice to use GitHub releases. The only thing I'm concerned about is how to update the index.json file to point the release's zip file before we actually make the release. Otherwise, it seems like you'd end up with a release zip file that contains an index.json that doesn't include the release it's a part of.

Maybe the best option is to create the releases uses GitHub releases but move the index.json file from the main source repository into a GitHub pages branch?

[per1234]

I agree about (1). The release system seems logical because it is a standard Github way of creating versions but I can see two downsides:

• If you target the release on the ide-1.6.x-boards-manager branch then the zip file is automatically created but it may be confusing for people who try to do a manual install of the release and find that the folder structure is different. A solution to this would be to base the release on the other branch and then manually create the boards manager install file and add it to the release with wording to explain what it is. Then there would be little purpose for having the ide-1.6.x-boards-manager branch and you could just have the gh-pages branch with the .json file.
• You will have to be responsible for doing the releases because you can't create them via pull request. It would be nice if the person making a pull request that creates a new version could also be responsible for updating the Boards Manager install file and the .json file and you could just merge the PRs.

[per1234]

One thing to consider about moving the .json file is that it will break the link for anyone who has already added the current URL to their Preferences.

[damellis]

The more I think about it, the more it seems like a good idea to move the .json file out of the repository. It seems awkward to have a file that refers to snapshots of a repository within that repository. Putting it in GitHub pages seems like the best option, since it will still get versioned controlled that way. Breaking existing links is unfortunate, but I think it's okay.

I think it's probably still useful to maintain a branch that contains the ATtiny files in the structure / location that's expected by the package manager, even if that means that people doing a manual install need to use another branch. Will the current ide-1.6.x-boards-manager branch provide the right folder structure when (if?) it gets automatically zipped as part of a GitHub release? If not, let's change it so it does.

Should I remove the .json file from the ide-1.6.x-boards-manager branch and make a release? Then you can create a pull request to add the appropriate .json file to the gh-pages branch?

[per1234]

If you target the releases on the ide-1.6.x-boards-manager branch as it is currently then Github will automatically create the zip file with the correct structure as Source code (zip) under Downloads. The question is whether Github will change the checksum of the automatically generated zip file over time? The releases will show up regardless of the branch that the user has selected so I think my concern of a ide-1.6.x-boards-manager branch targeted release being potentially confusing to the user that wants to do a manual install of that release still stands unless some steps are taken to make it clear what is going on or having a manual install file as well as the boards manager install file in the release.

I would also need you to create the gh-pages branch as I don't think there is any way for me to create branches via PR.

[damellis]

Closing this since we've already pointed a lot of people at the json file in the repository.

[per1234]

The issue of the checksum value changing hasn't reoccurred in over a year now so I think the current system is fine. Maybe this issue was caused by a force push?

I agree that it's important to maintain the same Boards Manager URL now that users have added it to their preferences.