Here's a little bit different option than what we've discussed:
A Different Possible Work Flow:* Sydney works on the moon replacement. We would focus on
just getting something reasonable -- shading, shape, etc. Speed is important here.
* Bugsbane works on a Turtle Boss replacement. We ask him to just come up with something
"that works" for now and do the really good replacement later. This is done in
* He also might look into resizing some of the existing army SVG sprites into Army
boss sprites. There may not be a 1:1 correspondence, in which case gaps would need to be
* We continue following up on Johan's licensing and anything else deemed critical or
high priority in parallel
* A better moon replacement is done later.* A better army boss replacement is done later.
Before this effort is started, we'd have to get:* Time estimates for both the Army
boss and moon replacements. It should take less time if we use a quick replacement
option.* Availability estimates - how much time do Sydney and Bugsbane have now, and when
is it likely to be completed (we won't hold them to the fire at all of course --
it's all volunteer)?
I think it's worth asking this question before dropping the turtle boss from release
2.0. I'd like to be done with the release, too, but I think we really should ask
these questions before purging long standing features that were in SMC 1.9.
It's also worth asking what the likelihood of a Nintendo lawyer or Linux distributor
complaining about the existing turtle boss or moon sprite graphics are.
We really should post this discussion in a ticket in github - not everyone uses the
mailing list (ie Bugsbane does not use mailing lists). People may not check IRC logs,
either. github seems to get more responses right now than the other venues we use.
On Sunday, February 22, 2015 4:56 AM, Chris Jacobsen <cjj_009(a)yahoo.com>
"datahead wants to make 2.0.0 a really good release with lots of new
features." --No, I don't want to add new features to release 2.0. I was
concerned about removing existing features such as the turtle boss in the release. We
should think carefully before doing this. I also had reasoned we'd want to be
reasonably deMarioized before the release as much as feasibel (and not look over-buggy).
This release is the first in 5 years and the first TSC series release -- this is why I
thought this is worth considering.
"Luiji wants to take the opportunity to wipe out the backward compatibility code
right now."--As I understand it, he had last suggested having .smclvl files use the
old data format and .tsclvl's use the new format, which would not break
compatibility. Before suggesting this, yes, he did suggest breaking compatibility in
release 2.0. Luiji can correct me on any of this as needed.
On Sunday, February 22, 2015 4:42 AM, Quintus <quintus(a)quintilianus.eu> wrote:
So this discussion has come up on IRC again, with the additional aspect
of what to make of 2.0.0 at all. and I would like to sort it
out properly. So far, I have seen the following positions:
* datahead wants to make 2.0.0 a really good release with lots of new
* Luiji wants to take the opportunity to wipe out the backward
compatibility code right now.
* Bugsbane would like to have a larger time frame to submit more
graphics for 2.0.0
* I want a release as soon as possible so we have something to show.
I repeat we are already in beta phase for 2.0.0 and I’m strictly against
introducing new code features. How would you manage to do this? The
devel branch has been changed by Brian heavily (in very good ways!), so
it is unfeasable to introduce that into 2.0.0 as it’s lots of unstable
development code. Also, allowing new features albeit we froze the 2.0.0
version earlier already would delay the release probably somewhere into
2016 or later. That can’t be really the goal. Breaking the beta plan we
had out there also looks inconsistent.
On the other hand I don’t want to have all the previous SMC users
refrain from switching to TSC, so some degree of backward compatibility
to at least 1.9 seems warranted.
Expanding the time frame even more doesn’t seem useful to me neither. We
have been in beta phase for several months now, and we ought to release
something now. We can’t roll on in beta eternally. After the 2.0.0
release, we have the window open again for any new features, and may be
able to do some more or less quick series of followup releases.
Luiji suggested doing prereleases, but thinking about that, how is this
different from beta releases actually? In fact, beta releases _are_
prereleases, thus we have beein doing prereleases all the time already.
As far as I am concerned, I would like to confirm licensing with Johan,
replace the moon with something else, and then do the release, probably
removing the turtle boss as I have suggested on IRC. There are no
critical code bugs left that would prevent that.
Please, followup on this. We really need to come to a conclusion.
Quintus <quintus(a)quintilianus.eu> writes:
I have noticed we have some problem with regard to our backward
compatibility conception. Last evidence was in ticket #354.
We are in the beta phase of 2.0.0 already and I don’t want to throw it
all around and introduce major code changes now while we are bugfixing
mainly (and replacing Marioesk music). The 2.0.0 release is basically
the completion of the SMC series, and for our first release I think it
is important to allow users of the old SMC game to easily “upgrade”. Old
SMC is, as far as I can tell, still pretty commonly used so I think it’s
better if we take those people with us without having them to guide
through some level format conversion tool for now.
I don’t think the 2.x series will last long anyway. Our tracker is full
of feature requests, some of which require breaking existing code,
and we still have too much legacy code in the codebase as too just
shifting it around with us. After the 2.0.0 release, I imagine we’re
going to implement features for 2.1.0 quickly, and simultaneously start
a 3.0.0 development branch in which we implement the
backward-compatibility breaks. Under this conception we probably only
have some few releases in the 2.x series.
We will also probably suffer from a credibility damage if we stopped
beta and went back into development again. Who has ever seen such a
(whose email signature is becoming far too long)
I will reject HTML emails. | Ich akzeptiere keine HTML-Nachrichten.
Use GnuPG for mail encryption: | GnuPG für Mail-Verschlüsselung:
My key fingerprint: | Mein Schlüsselabdruck:
B1FE 958E D5E8 468E AA20 | B1FE 958E D5E8 468E AA20
8F4B F1D8 799F BCC8 BC4F | 8F4B F1D8 799F BCC8 BC4F