| |
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. |
|
... 53 posts hidden. Click here to view all posts....
|
| |
MagerValp
Registered: Dec 2001
Posts: 1078 |
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. |
| |
hedning
Registered: Mar 2009
Posts: 4731 |
Quote: 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.
Good idea. Some bugged release-icon should be easy to implement as "broken" already is tagged, as well a field for pointing to a fixed release, if available.
I agree on the rest as well: best way to cope is to make sure your release is ok before a release. |
| |
Bacchus
Registered: Jan 2002
Posts: 156 |
I agree, the best way to ensure this is no issue is that you never release anything with bugs. Anybody who ever dealt with software will know: this is utopia. We need to have systems to cope with bugs. A world of software will inevitably have bugs. Always!
I made the effort in illustrating how I would like to see it presented:
https://www.dropbox.com/s/wb8kcfjkvdk8v3j/example.png?dl=0
(And my Paint Program Fu sucks - it's a mock-up ok?)
# It satisfies the need to archivers to have all versions available.
# It satisfies those interested to play the games to find a current version that actually works (minimises the risk of picking the bugged one)
# It satisfies the cracker that the release is kept as one (and gives a framework for updates)
# It satisfies the need for the scene to put relevant shame and bad karma over those providing sloppy releases
Status Broken would then only be used to mark the most recent version as broken. The old versions are obviously inferior if they needed to be replaced.
Please mind that would give incentives to update cracks. I would consider making IFFL version of games that I previously released as file based. On some cracks you realise that adding a new trainer or two would be beneficial. The above would be a great vehicle to accommodate keeping the versions together, as they are logically the same but with minor adjustments.
There is no contradiction between this and MagerValps opinion of keeping major releases separate and have references between them. Up to the uploader to tell if the new version is a minor or major update.
Pleas elaborate over which aspects this doesn't satisfy! |
| |
spider-j
Registered: Oct 2004
Posts: 498 |
I don't think grouping multiple files / versions in one entry is the way to go as this would only work for buggy cracks / demos and not for tool updates (i.e. version number in the release title). But I agree that it would be nice to have a place for the information about newer / bugfixed versions somewhere else than only in the comments.
In this special case: If you want to avoid confusion, just use the release title:
Supergame+
Supergame+ Final
Supergame+ Final V2
;-) |
| |
chatGPZ
Registered: Dec 2001
Posts: 11384 |
cool a mockup \o/
i like how you make it appear as if it'd be a huge problem. you are planning to fuck it up often, are you? |
| |
Bacchus
Registered: Jan 2002
Posts: 156 |
Groepaz - how about picking up on the questions?
How is my suggestion NOT a valid improvement?
I would be kewl if you say it's a good thing but it's on spot 1007 on the priority list for implementation. Or that it sucks for reasons X, Y and Z (like you do on the VICE list). Here you are just being arrogant. "Fuck you - things are good as they are" kinda attitude.
No I don't plan to fuck up. But users of CSDB don't deserve to be the victims when it happens! |
| |
Bacchus
Registered: Jan 2002
Posts: 156 |
Quote: I don't think grouping multiple files / versions in one entry is the way to go as this would only work for buggy cracks / demos and not for tool updates (i.e. version number in the release title). But I agree that it would be nice to have a place for the information about newer / bugfixed versions somewhere else than only in the comments.
In this special case: If you want to avoid confusion, just use the release title:
Supergame+
Supergame+ Final
Supergame+ Final V2
;-)
As I say in my text above;
- One solution for cracks and demos that get updates/fixes and tools with minor releases
- One other solution for major updates |
| |
chatGPZ
Registered: Dec 2001
Posts: 11384 |
i think you are still missing the point on what csdb is about, and what it wants to be and what not.
what csdb is about:
- csdb is an archive, csdb collects all releases, buggy or not, intended or not, liked or not.
what csdb is not about and does not want to be:
- a software development platform with version tracking (use github or sourceforge or whatever else you prefer)
- a release outlet (use your homepage, upload to some ftps, use the boards, use forums)
- a BBS (use telnet for this)
- a fronted for gamers to find the best release of a game (there is gamebase for this)
- part of the warezdrama scene (use the BBSs for that)
what you are proposing just doesn't solve an actual problem. it would be very much needed IF releasing different versions of the same release would be a common thing in c64 world. but (thank god for this) it is not. quite the contrary - its pretty rare and doesnt happen often at all. so sure, once all the other much more important things on the 100 miles long TODO list have been added, someone may have a look at it and give it a go. at the current speed of development your grandchildren may enjoy flawless versioning on csdb.
that said, i actually really think that those who fuck up their so called first-releases should get punished and exposed. and that csdb shouldnt actually encourage this nonsense by adding features that makes it easier or less annoying to handle. |
| |
Bacchus
Registered: Jan 2002
Posts: 156 |
Thanks - fair answer. Not witty reply but something you really put your head into. Much appreciated!
I'm more than happy to have a conclusion that in order to best support the *visibility* it might make sense to do it like as per my mock-up. But that it was silly low in priority.
Then I have achieved something with the discussion. |
| |
Bacchus
Registered: Jan 2002
Posts: 156 |
And adding to that;
- It's indeed *not* Github. If it was then we'd add all builds of a program - possibly some archiever would want that in order to capture EVERY revision of work in progress :-P
- It's indeed a release outlet for a number of people. Scene releasing is separate, but it happens on CSDB as well. Why shouldn't it? There is no point in adding stuff to CSDB much later than putting it out somewhere else, is there?
- A BBS is a function for files and discussions - CSDB has both. The Forum is for sure a discussion boards as good as any BBS.
- A front-end to pick up games? Well people are using it for that. I would argue that that is what a lot of people primarily use it for. So here the internal perception might be in total disharmony with the external...
- And I agree that the warez scene is separate. It's an agreed mechanism for what releases to count and how to count. Having said this, I can't see why they couldn't count stuff that was put online on CSDB if they chose to, and CSBD can't do anything about that someone else is making a point system based on what appears on CSDB. But that's a discussion for those making the point systems.
And;
I assume the "real problem" by your definition is the releases of bugged versions. I agree that is a problem.
But that should be a scene problem. And did someone just say that CSDB is not the scene - is merely an archiving site. It's not the place to cast bad karma and involve in scen politics. And yet that seems to be a few people main objective. I think a few people need to think that over another round ... I have my mind clear on the matter! |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 - Next |
