| |
Bacchus
Registered: Jan 2002
Posts: 156 |
Recall releases
# Background
I messed up. We released a version of Tink's Subtraction that was bugged. The trainer poked maximum values in the registries on every load. But the max value was different depending on the level chosen to play at. I did a quick fix and released the new one where this aspect was perfected.
Then it showed that it also loaded one of the levels differently if you selected another difficulty level, so I needed to make a new fix and then also another version.
# What conflicting interests to take into account?
I think it's fair view that if you release shit and are sloppy in your quality assurance, it's only right if there is a level of embarrassment involved. At least to some extent.
It's also a fair view that preservers want all versions. At least to some extent.
But it is also worth taking into account that we also don't want people to pick up the wrong version of a game and spread it.
# Suggestions:
> Having said the above, I don't see the value in bugged versions risking to be spread over the final ones.
I want to be able to recall a release. I know this collides with the "preserve all" and the that I'm not properly dragged through the mud for sloppy work, but the bugged one is out of circulation.
I can edit comments - why not as a bare minimum give me the right to adjust (including removal) a release for the same duration as editing comments?
> If this is not possible, then I would want the option to issue a "replacement". I need to upload a new version which has a clear indicator that there was a previous - bugged version - that got replaced. Mud dragging and no spreading of the bugged one. Only counter argument is the access for the handful of people who see the benefit in that, intermediate, version.
> At least delete the download link for broken and replaced releases, and give the three people globally interested in preserving such bugged and replaced releases the option to download them separately. |
|
| |
hedning
Registered: Mar 2009
Posts: 4731 |
My view:
We all mess up. All my and other's sins are here to see and explore. Many times I would have liked to "recall" a release, but how do you really do that? It only takes one (1) download for the file to be potentially spread everywhere, thus being released. It's a fact that you can't recall a release. If something is released it's released. If we revoked the release we would be lying. I fully understand that people would like to have embarrassing (whatever reason) releases taken away and forgotten, but if we did that we would be promoting historical revisionism.
The rule to preserve everything here actually have two purposes: 1. The file was officially released, and thus it should have an entry here, fuckuped or not. If it's not 100% working; well - then we have purpose 2: Don't fuck up. Test the shit out of your releases and make sure you don't screw up. Test it even more, and then release it. The rule actually promotes better quality releases - hopefully.
Your third solution makes more sense. The release is archived and the interested people can still keep it, but it is not spread to other normal users, and unregistered leechers, that only want the working crack. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11384 |
imho uploading a release equals copying it to a disk and mailing it to your contacts. its out. deal with it.
if anything, it should make you think about whether rushing out these cracks for silly firstrelease points is the way to go in 2017.
(you can switch download link to "only visible when logged in" if you really give a damn) |
| |
Bacchus
Registered: Jan 2002
Posts: 156 |
My suggestion is:
* Allow to upload a new file - and marking the old one as not valid - giving a reason. (Keep the old one for reference if this is important to some people)
* Give a rating for how well a group or person maintains only the first upload of their program.
=> S T O P penalising the CSDB users by exposing them with multiple releases of the same releases. It's so confusing, and I am positive only a handful of people want to have fixed versions as separate ...
Please mind:
If I release a game with file loader and then release an IFFL version, then that IFFL version is a new version. They should have separate CSDB entries.
If I release a version with a graphics bug and then correct it, this is the same version. And they should have the same entry.
Debugged and functionally different must be different. |
| |
Seven
Registered: Jan 2002
Posts: 202 |
Isn't the "Proper release" flag a sufficient indicator to let people know that a version is bugged and shouldn't be the one downloaded to play? Maybe it makes sense to put that indicator in the list view as well. |
| |
MagerValp
Registered: Dec 2001
Posts: 1078 |
Adding a field that says this release is an updated version of <ID> would solve the problem neatly. Everything gets a new entry, the way it should be imho, but deprecated entries can be clearly marked as such with a link to the preferred release. Especially useful for tools, e.g. when theres a new exomizer or sidwizard or ULoad etc. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11384 |
Quote:S T O P penalising the CSDB users by exposing them with multiple releases of the same releases. It's so confusing, and I am positive only a handful of people want to have fixed versions as separate
csdb collects all releases, and all releases get their own entry. its that simple.
and what seven said. and magervalp :) |
| |
Bacchus
Registered: Jan 2002
Posts: 156 |
Quote: Isn't the "Proper release" flag a sufficient indicator to let people know that a version is bugged and shouldn't be the one downloaded to play? Maybe it makes sense to put that indicator in the list view as well.
It's confusing to have multiple version of the very same program from the same group with only small patches as difference. If you are on one of the bugged, there is no automatic way of telling where the proper one is. That needs to be posted in the comments.
# Hold the same version together as a release - one entry - but allow upload of an updated binary.
# Keep all binaries and maintain a comment why it was made obsolete. I'm perfectly fine with the remark "Bacchus fucked up - pick up the fixed version and this one".
# Warn the user if they insist downloading the bugged version.
# Bonus: Keeps score of groups maitaining quality by never needing to upload a second version.
Please mind that we already replace broken versions if the error are due to transfer error or such. There it's important to share the proper version and not the bugged ones. There the originator can provide a new one.
But I guess that if I post the release with an external URL then I can update the d64 as I want and nobody could have any opinion about it. |
| |
Seven
Registered: Jan 2002
Posts: 202 |
How about we only keep the BEST version of ANY game to protect poor users from downloading an inferior version?
There's a clear difference between a transfer error due to a degraded disk, and a group release that just happens to be borked because the cracker couldn't be bothered to test his work properly. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11384 |
external links will be replaced by internal ones asap for exactly this reason (and because they disappear sooner or later).
anyhow, this all is hardly a problem.
and the confusing part is that it takes fairlight 3 tries to make a working crack of a children education game. |
| |
Bacchus
Registered: Jan 2002
Posts: 156 |
Quote: Quote:S T O P penalising the CSDB users by exposing them with multiple releases of the same releases. It's so confusing, and I am positive only a handful of people want to have fixed versions as separate
csdb collects all releases, and all releases get their own entry. its that simple.
and what seven said. and magervalp :)
Well MagerValp at least wanted a way to automate deprecation of old versions. So in a sense he proposes a vehicle to obsolete versions that are no longer current. I strongly support that.
All I add that that is that for minor adjustments I strongly suggest that this is done within the same release.
99% of all want the working release of program x. But we might want to facilitate that the 1% keeping all versions - including the bugged ones - and that we ensure that all the people who are keen to prevent sloppy releases, are also properly satisfied.
I think a fair balance is having minor iteration inside the release (as per my suggestion) and then the major version between releases (as per MagerValps suggestion).
On the "csdb collects all releases, and all releases get their own entry. its that simple." that it is how it is today. There is nothing saying that you cannot improve. This is not a BBS - we are allowed to make progress. It is that simple today. Nobody questions that. Does it hav e to be that tomorrow? No indeed not. |
... 53 posts hidden. Click here to view all posts....
|
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 - Next |
