<br><br><div class="gmail_quote">On Mon, Jul 14, 2008 at 5:34 PM, C. Scott Ananian <<a href="mailto:cscott@laptop.org">cscott@laptop.org</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="Ih2E3d">On Mon, Jul 14, 2008 at 4:49 PM, Eben Eliason <<a href="mailto:eben.eliason@gmail.com">eben.eliason@gmail.com</a>> wrote:<br>
> I'm not sure this satisfies me. It might accurately handle the use case of<br>
> updating when upgrading, assuming that activity developers are very careful<br>
> to add extra info about compatibility into the .info file. It doesn't<br>
> however, make it easy to decide what version of an activity to download if<br>
> I've never used it before, and I'm not on the most recent release of Sugar.<br>
<br>
</div>No, this problem is already solved by the scheme I outline.</blockquote><div><br></div><div>Can you explain how? For instance, if I'm looking at a wiki page for an activity, how does that page tell me which version I need? How can a tech-support guru tell the person on the other end of the line what they need? It seems your approach only works when software is working it's magic on the extra info in the .info file.</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><br>
<div class="Ih2E3d"><br>
> I agree with the signature approach. However, I don't really know what<br>
> happens when I have 37, 38, and 39 where 39 is a "bugfix" release of 37, and<br>
> 39 is a "brand new version"...I'd prefer to see them ordered 37, 39, 38, to<br>
> coincide with the "level of newness". This is something we will lose<br>
> completely without a minor release number. The logical assumption is that<br>
> "the bigger the number, the better/newer it is", which is blatantly false<br>
> when point releases are intermixed with brand new versions with<br>
> ever-increasing version numbers. I might decide I need to clear up space,<br>
> and so delete versions 37 and 38, thinking I was keeping the latest and<br>
> greatest version 39 and be quite disappointed.<br>
<br>
</div>I don't see how your solution solves this problem either. Say the<br>
activity author has released 0.4, 0.6, 1, 1.2, and 1.3. Versions 0.6,<br>
1.2, and 1.3 only work on 8.1 (because of a bug in 1.3), but version<br>
0.4 and 1.2 work on 8.2 (because 0.4 didn't use the "new" feature that<br>
was broken in the 8.2 update, and 1.2 didn't have the bug introduced<br>
in 1.3). What's the "level of newness"?<br></blockquote><div><br></div><div>I still think it mostly solves it. You're confusing "newer version of an activity" with "runs on newer version of OS", I think. For instance, even though 0.4 runs on 8.2 because it didn't use some new feature of 8.1 doesn't make it any newer. It's still old, less mature code, and the UI and feature set would certainly back that up. The bugfixes in 1.2 might also make the activity work on both 8.1 and 8.2, but that doesn't change the fact that the fixes were still to a version of the activity less mature than 1.3, and likewise containing fewer features.</div>
<div><br></div><div>Most importantly, you've demonstrated that the "natural ordering" of the versions is 0.4, 0.6, 1.2, 1.3, which is true regardless of the fact that 1.2 might have been released months after 1.3. The level of newness seems intact to me.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Sadly, I think that it's up to the activity authors to ensure that<br>
newer versions work on older releases. I admire your desire to make<br>
more powerful version numbers, but simply adding an extra digit isn't<br>
going to materially change anything.<br></blockquote><div><br></div><div>I think you're wrong. I think that exposing single digit version numbers is, subconsciously or not, going to indicate to them that the largest number is the newest version of the activity. The problem is that the definition of newest isn't in sync with expectation. It's only newest in that it was released most recently, but that's not what really matters. What matters is which of them is the most mature in terms of code/features.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
I think the most interesting question is "what's the newest version<br>
compatible with my release", and that's the problem I've solved. I</blockquote><div><br></div><div>Again, I disagree. Take, for instance, your example from above. It was clear that both versions 1.2 and 1.3 work on 8.2. If 1.2 was released after (temporally) 1.3, it's technically "newer" and would have a higher version number (in the old scheme). It's also compatible with 8.2. So the newest version compatible with my release is therefore 1.2, even though there's actually a newer-as-in-features 1.3 release that I'm really after.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
agree that it would be interesting in the future to be able to mark<br>
activities in the activity list that "can't possibly be expected to<br>
run" for some reason or another (like an API incompatibility), but I<br>
don't think I agree that manually putting information in an<br>
<a href="http://activity.info" target="_blank">activity.info</a> file is the best way to do that -- for starters, the<br>
information you'd like to add all have to find its way into that file<br>
*retroactively* after the new release has come out which is<br>
incompatible. A better method would be to provide a standardized way</blockquote><div><br></div><div>What? All I'm suggesting is a minor version number. Nothing needs to be added retroactively to existing activities. We can just assume that absence of a minor version means that it's X.0 instead.</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><br>
for a python app to run code which performs tests and returns a<br>
go/no-go, or else to just mark activities which fail during launch.<br>
--scott<br></blockquote></div><div><br></div>- Eben<br><div><span class="Apple-style-span" style="color: rgb(136, 136, 136);"><br></span></div>