I want to propose this since I've been making more use of it in recent projects. When we archived the old LGM versions we stuck them in our dropboxes which is, despite me having created a shared ENIGMA dropbox, still subject to link rot. I never did attempt to migrate our old and new releases to GitHub because I never understood the feature until now.
Basically if we move all of the ENIGMA ZIP's, old LGM jars, and all those old revisions and packages over to the GitHub release pages we get static links.
For example:
https://github.com/IsmAvatar/LateralGM/releaseshttps://github.com/IsmAvatar/LateralGM/releases/download/1.5.7.1/lateralgm1571.jarInstead of what we have now on the LateralGM: Revisions Wiki page:
https://www.dropbox.com/s/jrigtjk0yld8zsy/lateralgm1571.jarNotice how the GitHub version is not subject to link rot? This is by GitHub's own design for the very reason we are intending to use it. Using the GitHub release pages also allows me to archive the change logs in the description. This is important because our forum is also subject to link rot as topics are moved and the forum board evolves, people will still be able to find the change log well into the future (considering GitHub is probably more likely to be around in 10 to 20 years than we are). This also means we don't have to make so much use of third parties like dropbox since setting up proper file transfer to ENIGMA's server would be a lot of work and cumbersome to say the least (which is why we are still struggling to finish the EDC). This also means that every contributor can establish a release if they have appropriate access to the repository.
There are some things that need addressed. Primarily the GitHub release mechanism automatically versions the repository and detects change logs. So if you don't enter a description it automatically detects the changes made to the repository since the last release was made, which we can make more effective use of in the future. This will make our initial migration of the old releases cumbersome though as I'll have to paste all of the change logs there and you'll just have to ignore the one GitHub shows in cases where a change log can't be found (I have them for all of my releases just not LGM 1571), which is not that big of a deal. This also means however that ENIGMA needs to establish version numbering and so do all of the other projects including JEIE, etc etc.
Once this is done however I would update all the appropriate documentation on the Wiki and related links. I would not delete the old revisions archived on our shared dropbox but the Wiki and everything would be updated to reflect the new release process. I also would not delete the old revisions page right away until some point in the future when the links become broken or our shared dropbox has been fragmented.
http://enigma-dev.org/docs/Wiki/LateralGM:_RevisionsI would continue to maintain the Extra Packages page for quick links to all of the latest releases. The page would just be updated with the rest of the Wiki.
http://enigma-dev.org/docs/Wiki/Install:Extra_PackagesI've experimented with archiving two old releases of LateralGM on its repository.
https://github.com/IsmAvatar/LateralGM/releasesI also believe this would reduce the confusion of random people finding LateralGM through Google and not knowing where to download it. The GitHub release mechanism is pretty common and you know people have come to get used to it, myself included. It also makes formatting the change logs nicer by allowing us to use markdown and link to specific tickets instead of by URL like I do now.
I'd like to know what you all think about this, I think this is the way to go and I am looking to do all the footwork to make the change. I'd just like to take some feedback and suggestions on it first.
Also I will need additional privileges to a few repositories such as JEIE to do the releases which I asked IsmAvatar about before but never got a response, hopefully I can get a hold of her.
Edit: Actually it seems like it is possible when drafting the releases to base them on a certain commit, but I don't know how far back we'd have to dig. I could probably dig for all of the releases I made but maybe not the ones for 1.6 and 1.5 as they may not have been migrated from Sourceforge.