| |
Bacchus
Registered: Jan 2002 Posts: 154 |
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. |
|
... 53 posts hidden. Click here to view all posts.... |
| |
hedning
Registered: Mar 2009 Posts: 4621 |
I hear you. And I am just trying to explain how things work. My own views are for the moderators eyes only if and when we discuss this. :) |
| |
chatGPZ
Registered: Dec 2001 Posts: 11154 |
somehow it shows that bacchus is a noob regarding csdb :=) |
| |
Smasher
Registered: Feb 2003 Posts: 512 |
"lateral thinking" is solving problems through an indirect and creative approach. for more info: https://en.wikipedia.org/wiki/Lateral_thinking
so in this case: send your girlfriends/wives to Ian Coog, Ian will (hopefully) lose interest in debugging kindergarten games on c64, nobody else will ever find any bugs, no need to upload new versions, no need for this discussion, problem solved. :) |
| |
chatGPZ
Registered: Dec 2001 Posts: 11154 |
leave ian alone! |
| |
Tim Account closed
Registered: Mar 2002 Posts: 467 |
Well.. if nothing else this thread made me realize there actually IS a field that can be used to mark a release as broken by the maintainer. . Would genuinely have loved to know this recently.. and, although off and on over periods of time, I am by far new to csdb so thanks!
Nitpicking though, Id like to add that this field is almost as well hidden as the Youtube link field, which I only found purely accidental recently after seeing Hedning comment to a user placing a Youtube link in the comments (and even then it still took me a while to find the actual field).
IMHO Bacchus has a valid point that, from a layout perspective, there is room for improvement, or at least I find his comments valid as long as visuals such as marguee-scroll are displayed in a very prominent place near a download, rather than useful information regarding the actual file(s). |
| |
hedning
Registered: Mar 2009 Posts: 4621 |
Tim: These fields are pretty new, so no worries. And if you are active on CSDb, using it for research, uploading lost releases etc, helping the database (as all users should, and is the main purpose of getting an account here), you should see these fields often as they are there when you add a release. |
| |
iAN CooG
Registered: May 2002 Posts: 3142 |
ZeSmasher: I am not a dumpster for used/old wives, I only accept unused or mint conditions, and possibly, young girls. |
| |
Bacchus
Registered: Jan 2002 Posts: 154 |
Still haven't seen any argument why grouping minor revision of the same release being a bad thing.
I for one appreciate if bugs are found and could be corrected. And I sympathise with the idea of being shamed for fucking up.
All I say is that I feel the users are penalised with a cluttered user interface that could be solved by grouping the minor iterations as one. Would be kewl if someone addressed the issue if why that wouldn't be beneficial for all. |
| |
Didi
Registered: Nov 2011 Posts: 480 |
I second the request to show the mark "broken" in list view in some way (different icon? little bug?). Makes it easier on search to skip broken versions.
The CSDb "keep it all, even it is broken or shit" policy has been discussed quite often. The best way to cope with it is to test your releases carefully before publishing them. Especially with old games there is no need to rush. Take your time for intense testing and maybe even let someone neutral check it because often you do not recognize your own mistakes. |
| |
MagerValp
Registered: Dec 2001 Posts: 1060 |
I'm still in favor of keeping separate releases for the fuckups. It keeps the pressure on devs to test their shit before releasing, and it's a core tenet of the site that I agree with. My workaround for when I iterate (or just plain screw up) is to add a comment with a link to the fixed release (see Ultima IV Remastered V2.2 for an example).
I'd love it if we could formalize that with a field in the db, where e.g. 137951 is marked as being replaced by 138772, with the appropriate presentation changes. Multiple releases or downloads on the same page sound to me like more work for Perff, and more confusing for users. |
Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 - Next |