This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 »
391
Proposals / Editor Enhancement
« on: September 07, 2015, 08:11:23 pm »
So we are all aware of the traditional GM style editors:
We are all very comfortable with this to some degree, you save in the top left etc etc. But there's a problem here.
The tool bar buttons are never aligned with the content being edited. I propose that for LateralGM we move all the side panels on the room editor, path editor, sprite editor, and background editor to the right instead of the left.
With this change all of the toolbar buttons are properly aligned with the content area and requires less mouse dragging to click. What does everyone think about doing this? Since I realized this I've really come to like the idea. An alternative would be to move the toolbar in the content area (but this is gross if we keep it the edit panel on the left because I'm used to save being in the top left of the window). The other alternative is to simple right align the toolbar (though this also moves the save button to where you wouldn't expect it to be). Please let me know what you all think if I don't get enough feedback I may just end up doing this anyway.
The alternative looks like the following. To eliminate the whitespace we could put the save button in the bottom left like it is on the font editor and object editor then move the toolbar into the content area. I don't like this though because I am really used to the save button being in the top left.
As a preference it could also move the tree. The IDE would be either left or right oriented.
We are all very comfortable with this to some degree, you save in the top left etc etc. But there's a problem here.
The tool bar buttons are never aligned with the content being edited. I propose that for LateralGM we move all the side panels on the room editor, path editor, sprite editor, and background editor to the right instead of the left.
With this change all of the toolbar buttons are properly aligned with the content area and requires less mouse dragging to click. What does everyone think about doing this? Since I realized this I've really come to like the idea. An alternative would be to move the toolbar in the content area (but this is gross if we keep it the edit panel on the left because I'm used to save being in the top left of the window). The other alternative is to simple right align the toolbar (though this also moves the save button to where you wouldn't expect it to be). Please let me know what you all think if I don't get enough feedback I may just end up doing this anyway.
The alternative looks like the following. To eliminate the whitespace we could put the save button in the bottom left like it is on the font editor and object editor then move the toolbar into the content area. I don't like this though because I am really used to the save button being in the top left.
As a preference it could also move the tree. The IDE would be either left or right oriented.
392
Issues Help Desk / Re: Error opening the ENIGMA - Illegal character
« on: September 06, 2015, 10:44:52 pm »
Are you by chance running this in a virtual machine?
I ask because the problem is related to the following:
I've never actually seen this before but this probably 100% an issue with your Java installation because it's not able to create the preferences file in the system registry. That's not our doing because the Java preferences API is a public API that makes it easy to implement preferences and actually abstracts/hides the system registry from you and uses INI files on Linux and Mac.
So this basically suggests that it's the lack of privileges for modifying the system registry. Have you by chance modified the security profiles of your Java installation in any way? Is there anything atypical about your Java installation or computer configuration?
Also the log suggests you are running Windows 7, is this true? Or do you happen to be running Windows 7 in a virtual machine?
Edit: A quick Google search indicates that this could just be a problem with your computer.
https://groups.google.com/forum/#!topic/google-web-toolkit/LQfsBSwD_ug
As I mentioned it seems to be the result of lack of proper privileges to run the program.
I ask because the problem is related to the following:
Quote from: LGM Log
x80000002. Windows RegCreateKeyEx(...) returned error code 5.
I've never actually seen this before but this probably 100% an issue with your Java installation because it's not able to create the preferences file in the system registry. That's not our doing because the Java preferences API is a public API that makes it easy to implement preferences and actually abstracts/hides the system registry from you and uses INI files on Linux and Mac.
So this basically suggests that it's the lack of privileges for modifying the system registry. Have you by chance modified the security profiles of your Java installation in any way? Is there anything atypical about your Java installation or computer configuration?
Also the log suggests you are running Windows 7, is this true? Or do you happen to be running Windows 7 in a virtual machine?
Edit: A quick Google search indicates that this could just be a problem with your computer.
https://groups.google.com/forum/#!topic/google-web-toolkit/LQfsBSwD_ug
As I mentioned it seems to be the result of lack of proper privileges to run the program.
393
Issues Help Desk / Re: Error opening the ENIGMA - Illegal character
« on: September 06, 2015, 09:46:27 pm »
Hello Jhasper!
In order to better assist we will need some additional information from you.
* Is this the first time you've used ENIGMA or LateralGM before?
* Do you have administrative privileges on your account?
* Could you attempt to run LateralGM/ENIGMA with administrative privileges and see if the error is corrected?
* How did you attempt to open ENIGMA through enigma.exe or through double clicking the LateralGM jar file? I see you also attempted to start LateralGM from the command line, this will only work when you use LateralGM separately from ENIGMA. If you want to use LateralGM without compiling games feel free to move the jar file somewhere else on your computer.
In order to better assist we will need some additional information from you.
* Is this the first time you've used ENIGMA or LateralGM before?
* Do you have administrative privileges on your account?
* Could you attempt to run LateralGM/ENIGMA with administrative privileges and see if the error is corrected?
* How did you attempt to open ENIGMA through enigma.exe or through double clicking the LateralGM jar file? I see you also attempted to start LateralGM from the command line, this will only work when you use LateralGM separately from ENIGMA. If you want to use LateralGM without compiling games feel free to move the jar file somewhere else on your computer.
394
Developing ENIGMA / Re: Debuging the .dll
« on: September 05, 2015, 08:57:56 am »
Yes I know what you mean but at the same time it increases the chances that they will report such issues, even more of them than we may be aware. It's like shining a flash light in the dark.
395
Developing ENIGMA / Re: Migrate Releases
« on: September 05, 2015, 08:54:49 am »
I'm not so sure about that then Harri, I don't really think I like that idea either. I support the idea of distributing the change log with the release inside the ZIP, but I see no reason to add it to revision control, we would literally be revising our own revision logs (is this not what git should be doing for us?). I fully support people's ability to use ENIGMA or any software offline, even if you have internet there's many parts of the world that don't including a lot of public parks and such where it's nice to stick software on a thumb drive and away you go. I don't even know if you can get internet/wifi on a plane or not yet cuz 9/11. Anyway I did think that maybe we could set up that git change log generator project and make it auto commit with one of the many bots we have to a repository that contains change logs for all ENIGMA projects. But I didn't like that idea because of the same reason I don't like you suggesting it.
I always did the change log as a more human readable form of the git revision log for those who may not know how to use git. Because of my historic inability to make nice commits I've also used both github's revision history and the change logs I've made to find stuff.
I always did the change log as a more human readable form of the git revision log for those who may not know how to use git. Because of my historic inability to make nice commits I've also used both github's revision history and the change logs I've made to find stuff.
396
Developing ENIGMA / Re: Migrate Releases
« on: September 04, 2015, 10:44:42 pm »
Josh can you share the old ENIGMA copies with us if you have them on hand for me to archive on GitHub? I would also like to see the last ENIGMA zip I had on the shared dropbox up there too, so maybe we should call that v1 since it serves as an intermediate milestone to the latest version from r3. I like to keep archives of old versions because it helps with testing.
Also the new tags on LateralGM make it really easy to see what the master looked like for a particular release, which is one really good thing about this. I do not think I care much for milestones but still think we should use them, they are just watered down labels but they still help abstract the project progress.
Second, I too favor rolling releases because if we did automate the change log generation we could just make it against the most recent commit/PR in master. I don't like all of these granular changes and I've been working on making more inclusive PR's/commits. The real hard problem with this is that I try to fix one issue at a time and push it to GitHub to see if it fixes a problem. I don't like sending a large amount of commits with a fix for something only to later find out it didn't actually fix it. This is difficult because people do not like to test or help test, I am not referring to us, I am referring to users that report issues.
FYI: Maybe we don't even need change logs Harri with the GitHub compare feature.
https://github.com/blog/612-introducing-github-compare-view
https://help.github.com/articles/comparing-commits-across-time/
https://help.github.com/articles/comparing-commits-across-time/#comparing-tags
Also the new tags on LateralGM make it really easy to see what the master looked like for a particular release, which is one really good thing about this. I do not think I care much for milestones but still think we should use them, they are just watered down labels but they still help abstract the project progress.
Second, I too favor rolling releases because if we did automate the change log generation we could just make it against the most recent commit/PR in master. I don't like all of these granular changes and I've been working on making more inclusive PR's/commits. The real hard problem with this is that I try to fix one issue at a time and push it to GitHub to see if it fixes a problem. I don't like sending a large amount of commits with a fix for something only to later find out it didn't actually fix it. This is difficult because people do not like to test or help test, I am not referring to us, I am referring to users that report issues.
FYI: Maybe we don't even need change logs Harri with the GitHub compare feature.
https://github.com/blog/612-introducing-github-compare-view
https://help.github.com/articles/comparing-commits-across-time/
https://help.github.com/articles/comparing-commits-across-time/#comparing-tags
397
Developing ENIGMA / Re: Debuging the .dll
« on: September 04, 2015, 10:31:20 pm »
Are you guys ignoring my post about Breakpad? It's a really good idea, lets you debug without having debug symbols in the code using Google technology.
398
Developing ENIGMA / Re: Migrate Releases
« on: September 04, 2015, 10:26:34 pm »Quote from: TheExDeus
Maybe we need to add a changelog in the repo as well, so that when a person downloads the release from github he can still see what has changed (even if the forum dies for example).The problem with this is that if the release log is verbose/long then it is really hard to browse for other releases. The simple thing is to say to just make the release log shorter but that's not always feasible. The other solution is to make more frequent releases so the logs stay smaller. Personally I think GitHub should improve the releases feature by making the browse part short descriptions then clicking on the release gives a change log and a longer description, maybe I'll file an enhancement request/suggestion. Though I doubt they'll care what I think since they don't even listen to Linux Torvalds who created git.
Quote from: TheExDeus
And how do we start versioning ENIGMA? Just start at 1 or something? I personally think ENIGMA is working enough to actually be considered version 1 right now (except the LGM crashes).I believe ENIGMA already had a version process and we're technically still working on r4... This would be a question for Josh. Josh has stated in IRC that he has old copies of r3 that should be able to run which I'd like to see archived on GitHub releases page with the newer portables just for historical purposes.
Quote from: TheExDeus
I kind of liked smaller versions previously (like 1.21, 1.22, 1.3 etc.) but it seems the current trend for a few years now is just increment the version by 1. So we get firefox 40.0.3 now and so on. So the after dot revisions are bugfixes and almost every feature is a major revision.I too like smaller revision numbers in case you didn't notice we never got to LGM 2.0 yet. I think Josh also tried to persuade me into smaller version numbers before.
Quote from: TheExDeus
We should also create milestones, so we know when to release instead of on every commit.I forgot about the milestones API.
https://guides.github.com/features/issues/
But there's also the difference in annotated vs. lightweight git tags. Tags are built into git, not a GitHub feature, releases is a GitHub feature. Releases have a 1 to 1 correspondence with tags and tags have a many to 1 relationship with commits. A lightweight tag just references a commit "git tag -l v1.2 a1a1a1a" where a1a1a1a is the first 7 alphanumeric characters of the commit hash/number. Annotated tags can reference other objects or you can create them when committing using -m to enter a message or w/e and say something like "This commit marks the completion of v1.2"
The fact that tags and releases are 1 to 1 really screwed with my head at first, this means you have to make a new tag for every new release, you can't reuse tags. I really found this to be quite odd, so the direct links will always be a little redundant.
https://github.com/IsmAvatar/LateralGM/releases/download/v1.8.6.844/lateralgm186844.jar
See what I mean? We could just rename the jars to just plain lateralgm.jar but I don't like that because then you can't download them all at once easily, you have to download then rename download then rename etc. Open to changing this though because it would make it easier to include in the packages file in the one ENIGMA repo that it uses to update on Linux using that script, which has to be changed to include the updated hash of the jar anyway to see if it's newer. On the other hand I should mention that nobody else on GitHub uses the same file name for every release like I just proposed.
Quote from: TheExDeus
Also, can github create a release for the current master automatically? Like instead of a specific version release the top one is always the current up-to-date one (like "beta" releases). I guess all of that must be done manually?Yes, that's how I did the last 1.8.6.844 release you just create the tag on GitHub. I used the command line to create the tags for the really old commits because GitHub only shows a list of recent commits to create a tag. Just draft a new release, open the "Recent Commits" under @target and select the top one.
Now the other thing to mention is that I lied about GitHub creating change logs. This is really stupid because given both commit hashes/numbers you can do a diff from the command line with tags, GitHub really sucks at these things (why Torvalds does not merge pull requests from GitHub). However other people have invented some automation tools that generates change logs which could be integrated. But also as I said above I don't like putting the long change logs on the releases page because of how terrible it makes it to browse for an old release, this is why I plan to stick to small change logs for each release with a brief description and the forum post containing the longer change log for the foreseeable future, unless you can think of some better way to do it. I do agree with you that I'd rather have it on GitHub though where it's more permanent.
https://github.com/skywinder/github-changelog-generator
399
Developing ENIGMA / Re: Migrate Releases
« on: September 04, 2015, 03:13:27 pm »
Alright Josh is good with it. As a first experiment I've moved all of the LGM releases over there, it was a total pain digging up the old commit logs but I did the best I could. Best thing to do is just to make sure we do it every future release.
https://github.com/IsmAvatar/LateralGM/releases
I linked the forum posts with the change logs instead of putting them into the release description because most of them are super long which makes browsing that releases page a bore. I will continue to do this for future releases but may add some small additional details. From now on each new release of LateralGM and major build will be a new release on GitHub and a new forum post, so it won't be one long forum post as was done in the past.
I'll do the plugin jars next but I don't think I'll dig up the specific commits for them, I'll probably just base them all on the most recent commit then do it correctly for future releases. I believe we should continue to version the plugin against the LateralGM version but I'm not sure yet.
If we are going to do this for the ENIGMA portable zip then the ENIGMA tracker also needs to work out a proper version number and we need to start incrementing it to mark the releases.
So basically we can use the tags for marking major milestones or w/e and the releases can be generated for each major milestone/revision. Does everyone like this?
https://github.com/IsmAvatar/LateralGM/releases
I linked the forum posts with the change logs instead of putting them into the release description because most of them are super long which makes browsing that releases page a bore. I will continue to do this for future releases but may add some small additional details. From now on each new release of LateralGM and major build will be a new release on GitHub and a new forum post, so it won't be one long forum post as was done in the past.
I'll do the plugin jars next but I don't think I'll dig up the specific commits for them, I'll probably just base them all on the most recent commit then do it correctly for future releases. I believe we should continue to version the plugin against the LateralGM version but I'm not sure yet.
If we are going to do this for the ENIGMA portable zip then the ENIGMA tracker also needs to work out a proper version number and we need to start incrementing it to mark the releases.
So basically we can use the tags for marking major milestones or w/e and the releases can be generated for each major milestone/revision. Does everyone like this?
400
Developing ENIGMA / Re: Debuging the .dll
« on: September 04, 2015, 09:10:50 am »
FYI my post over here was somewhat related to this:
http://enigma-dev.org/forums/index.php?topic=2584
http://enigma-dev.org/forums/index.php?topic=2584
401
Programming Help / Re: date_date_string change format
« on: September 03, 2015, 08:19:08 am »
Ok that's weird, figured I would have documented that one, it's in fact, the only one I did not. I honestly have no idea anymore lol.
402
Programming Help / Re: date_date_string change format
« on: September 02, 2015, 03:25:36 pm »
Yeah but still I documented it to.
And I'm not suggesting anything, just that we create our own now or stick with the C++ one. Like if we ever add JS as a scripting language like Unity that we wrap the method to format it the same way.
And I'm not suggesting anything, just that we create our own now or stick with the C++ one. Like if we ever add JS as a scripting language like Unity that we wrap the method to format it the same way.
403
Off-Topic / Re: The curse of being a very wealthy indie developer
« on: September 02, 2015, 10:47:36 am »
I found the story interesting though nothing new. I've thought about this myself before, I think it's something we all think about at one point another if we were rich.
It some ways the thought depresses me but I would probably just continue to find more projects to work on. I've always had a money doesn't matter philosophy and that's the best way to look at life. It's not the answer to all your problems, just live your life the way you want and be happy with what you've done.
It some ways the thought depresses me but I would probably just continue to find more projects to work on. I've always had a money doesn't matter philosophy and that's the best way to look at life. It's not the answer to all your problems, just live your life the way you want and be happy with what you've done.
404
Proposals / Google Breakpad
« on: September 02, 2015, 08:56:49 am »
This is a cool library used in Firefox, Chrome, and Google Earth. It allows you to build an executable with no debugging symbols, the library will generate crash minidumps. The debugging symbols are saved during compilation of the executable though. Later when a crash occurs a separate program can take the minidump and the debug symbols and put them back together again to create a human readable stacktrace. So basically you can build an executable without debug information and still debug it.
https://code.google.com/p/google-breakpad/wiki/GettingStartedWithBreakpad
I think this would be something really useful to take advantage of in ENIGMA. It would allow our end users to make extremely efficient games but still debug them just as in every GM 8.1 or earlier GameMaker version. It would also give us extremely useful information when users report an ENIGMA crash to us on GitHub as we can cache and store the debug symbols for every release we've made or have them include it with the crash report.
Using it with end user games would be a little trickier though because it means when you release your game you have to hold on to a copy of your debug symbols and properly version your game. However I think I have already thought of a way around this. Since we already make use of zlib to archive the resources, we could also archive the debug symbols file right into the executable. While this would still increase the file size of executables to include the debug symbols the game would not run like shit because the symbols would be separated from the program code.
This would mean that anywhere a game is used it would run just as you would expect but you could also take any crash/minidump log it spits out and feed the executable and the dump file to a debugger to get a human readable stacktrace. We could also achieve GM8.1 and LGM style exception dialogs by just embedding it into every exe or make it an option if the users really care to squeeze out the few extra bytes in file size. Either way I think this could seriously improve the situation regarding debugging in both ENIGMA and its engine and end user games. I'd like to know what everyone thinks.
https://code.google.com/p/google-breakpad/wiki/GettingStartedWithBreakpad
I think this would be something really useful to take advantage of in ENIGMA. It would allow our end users to make extremely efficient games but still debug them just as in every GM 8.1 or earlier GameMaker version. It would also give us extremely useful information when users report an ENIGMA crash to us on GitHub as we can cache and store the debug symbols for every release we've made or have them include it with the crash report.
Using it with end user games would be a little trickier though because it means when you release your game you have to hold on to a copy of your debug symbols and properly version your game. However I think I have already thought of a way around this. Since we already make use of zlib to archive the resources, we could also archive the debug symbols file right into the executable. While this would still increase the file size of executables to include the debug symbols the game would not run like shit because the symbols would be separated from the program code.
This would mean that anywhere a game is used it would run just as you would expect but you could also take any crash/minidump log it spits out and feed the executable and the dump file to a debugger to get a human readable stacktrace. We could also achieve GM8.1 and LGM style exception dialogs by just embedding it into every exe or make it an option if the users really care to squeeze out the few extra bytes in file size. Either way I think this could seriously improve the situation regarding debugging in both ENIGMA and its engine and end user games. I'd like to know what everyone thinks.
405
Developing ENIGMA / Migrate Releases
« on: September 02, 2015, 01:49:20 am »
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/releases
https://github.com/IsmAvatar/LateralGM/releases/download/1.5.7.1/lateralgm1571.jar
Instead of what we have now on the LateralGM: Revisions Wiki page:
https://www.dropbox.com/s/jrigtjk0yld8zsy/lateralgm1571.jar
Notice 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:_Revisions
I 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_Packages
I've experimented with archiving two old releases of LateralGM on its repository.
https://github.com/IsmAvatar/LateralGM/releases
I 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.
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/releases
https://github.com/IsmAvatar/LateralGM/releases/download/1.5.7.1/lateralgm1571.jar
Instead of what we have now on the LateralGM: Revisions Wiki page:
https://www.dropbox.com/s/jrigtjk0yld8zsy/lateralgm1571.jar
Notice 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:_Revisions
I 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_Packages
I've experimented with archiving two old releases of LateralGM on its repository.
https://github.com/IsmAvatar/LateralGM/releases
I 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.
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 »