Winlibre and Upping our point release numbers
Man, reading these comments is fun. Did you all see that we are being included in this interesting collection of apps for windows users?
http://www.winlibre.com/en/Versions.php
Also check the numbers...I think I'm in favor of beginning to advance our version numbers higher up like firefox did, thunderbird, and gimp. Although numbering is quite superficial, maybe we should start doing full point release releases after 0.40. Maybe the next one is 0.50, then next 0.60, etc. (HINT: I'm working on the roadmap rework right now)
I am making the official push that our 1.0 of Inkscape is full 1.2 SVG compliance. By this, I mean we can accept and render a SVG 1.2 file. I think that developing the editing around this is important, but it is more important that we handle SVG 1.2. Maybe though someone can argue for Inkscape 1.0 being able to both render and edit an SVG 1.2 file.
However, our system works currently, so why change it, right? I do think though that we need to get a supa-advanced version of Inkscape out the gate as Microsoft is going to drop their WVG (their SVG makeover) soon, and then we know what that means...
I keep seeing in comments people saying how our app is very well developed for such an early release thus implying that the app is new. The public perceives an app through maturity on many levels. What do you all think?
Man, reading these comments is fun. Did you all see that we are being included in this interesting collection of apps for windows users?
Saw that... pretty interesting little package.
I keep seeing in comments people saying how our app is very well
developed
for such an early release thus implying that the app is new. The public perceives an app through maturity on many levels. What do you all think?
You're right that most people in the software community know that version numbers are superficial. But to the average user the logic is "the higher the number, the better the product". Plus most people never see anything pre 1.0. I've had people question why I would install Firefox 1.0 when they have IE which is 6.0... oy! So I agree that it's worth thinking about at the very least.
-Josh
On Thu, 2 Dec 2004, jon wrote:
Also check the numbers...I think I'm in favor of beginning to advance our version numbers higher up like firefox did, thunderbird, and gimp. Although numbering is quite superficial, maybe we should start doing full point release releases after 0.40. Maybe the next one is 0.50, then next 0.60, etc. (HINT: I'm working on the roadmap rework right now)
I prefer the major.minor[.point[.subpoint...]] format we're currently using and which is relatively standard in Open Source.
Treating version numbers like decimal numbers is a bad idea because you invariably run out of room, and engender unrealistic expectations about how close a specific future version is. I've been through that on some other projects and it's not pretty.
It's psychologically better for the project if we don't pretend that version numbers have predictive (rather than just descriptive) value, lest we find ourselves pressured to either extend a release cycle for too long, or rush things, because of the "expected" next version number.
Let's say we were using decimal version numbers and had reached 0.90...
Consider what would happen if we had to postpone roadmap items to maintain decently short release cycles like we did for 0.40 (effectively moving things out a release), it'd really suck if we'd been implying that 1.0 would necessarily be the next release.
Our options at that point would be:
* delay the release until all 1.0 features were done
(In my experience, overly long release cycles can really hurt a project; I'm sure you all could feel the strain from the length of the 0.40 release cycle. Now just imagine how much worse that would be with all the expectations of a 1.0 release looming...)
* release an unsatisfactory 1.0 before it's really done
(needless to say this would generate a lot of ill will)
* start using versions that asymptotically approached 1.0
(I think people would feel rather cheated by an 0.95 release under those circumstances)
I don't expect there to be that much slippage in our roadmap, but some future items are exceptionally ambitious and we need to allow for that.
The major version is our "marketing" number; let's not let marketing infect our release process, which is the inevitable result of "sexing up" minor release numbers.
Yes, if we keep the major.minor.point format, some people are going to think that e.g. 1.5 comes after 1.42. Maybe we should start including the implicit point release (.0) on our minor release numbers as other projects do.
...and yes, I admit the version number jump after the Sodipodi fork was rather cheap. :P
-mental
On Thu, Dec 02, 2004 at 06:12:55PM -0500, MenTaLguY wrote:
Treating version numbers like decimal numbers is a bad idea because you invariably run out of room, and engender unrealistic expectations about how close a specific future version is. I've been through that on some other projects and it's not pretty.
This is one of my major complaints about Perl. They treat their versions (internally) as decimal, and there's a lot of hidden magic that unexpectedly blows things up. Like going from 1.49 to 1.5, etc.
Yes, if we keep the major.minor.point format, some people are going to think that e.g. 1.5 comes after 1.42. Maybe we should start including the implicit point release (.0) on our minor release numbers as other projects do.
I support this method. It also gives us the option (if we can create a tight packaging cycle) to put major bug fixes (that don't require architectural changes) into a stable release. For example, we have 0.40.0 now, and now we're working on 0.41.0. If the libgc problems could be solved via some secret tunable we discover next week, we could put it into 0.40.1, and release it while also putting it into 0.41.0 development. All standard release branching.
I think what's held this up in the past as been just lack of testing/packaging time to deal with making modifications to the tagged release branch.
On Thu, 2 Dec 2004, Kees Cook wrote:
I support this method. It also gives us the option (if we can create a tight packaging cycle) to put major bug fixes (that don't require architectural changes) into a stable release. For example, we have 0.40.0 now, and now we're working on 0.41.0. If the libgc problems could be solved via some secret tunable we discover next week, we could put it into 0.40.1, and release it while also putting it into 0.41.0 development. All standard release branching.
I think what's held this up in the past as been just lack of testing/packaging time to deal with making modifications to the tagged release branch.
Don't forget that we actually did that for 0.39.1.
However, I do tend to agree with bulia that it'd be best to avoid an 0.40.1 release specifically, because of existing strong expectations about 0.41 and confusion about how we do our version numbering right now.
-mental
On Thu, 2 Dec 2004, MenTaLguY wrote:
On Thu, 2 Dec 2004, Kees Cook wrote:
I support this method. It also gives us the option (if we can create a tight packaging cycle) to put major bug fixes (that don't require architectural changes) into a stable release. For example, we have 0.40.0 now, and now we're working on 0.41.0. If the libgc problems could be solved via some secret tunable we discover next week, we could put it into 0.40.1, and release it while also putting it into 0.41.0 development. All standard release branching.
I think what's held this up in the past as been just lack of testing/packaging time to deal with making modifications to the tagged release branch.
Don't forget that we actually did that for 0.39.1.
However, I do tend to agree with bulia that it'd be best to avoid an 0.40.1 release specifically, because of existing strong expectations about 0.41 and confusion about how we do our version numbering right now.
Yup. Regarding packaging cycles, I think the process we've adopted has worked pretty well. We have very frequent (nightly) releases for people who want to really stay on the bleeding edge, but we make no promises that there's any Q.A or even that it'll necessarily work, so it's low commitment from a packaging point of view. And we have infrequent but highly Q.A.'d versions that people can use that are not keen on running unstable code and for whom an upgrade every few months fits well with their schedule, especially given how much new goodness each release has had.
So I like that for our "stable" series we use regular version numbers (0.38, 0.38.1, 0.39, etc.) and for our "devel" series we use build-dates. Makes it extremely clear that one is expected to be stable and one might not be.
I've also noticed that we've had few problems with communicating with users about what version they're using when reporting bugs, so this system seems to be working pretty well. The one change I'd suggest is for the devel versions to cause the build-date to be indicated in the about screen. That way if someone's running a nightly from 3 weeks ago, they won't get confused into thinking that they're running the stable 0.40 version.
I've often thought about if we should be porting bug fixes to the stable branch and create 0.40.1, 0.40.2, etc. Specifically what I'm watching for is someone to voice an interest in being the "stable series maintainer" and take on the role. Currently we have not heard strong interest in doing this from either developers or users, so my guess is that the time is still not quite right to take this approach. One of the main needs for this approach is for security issues, but since Inkscape is not really the type app that opens security holes there doesn't seem to be as much need.
Bryce
On Fri, 3 Dec 2004, Bryce wrote:
The one change I'd suggest is for the devel versions to cause the build-date to be indicated in the about screen. That way if someone's running a nightly from 3 weeks ago, they won't get confused into thinking that they're running the stable 0.40 version.
I agree with this and in fact it was being done in the "early" days last year :-) but it suddenly stopped (why?). It is particularly useful when (as I do I with win32 releases) you download a full package (14M) every couple of weeks or when there is a major change and in between bring down .exes or .exe zips. These latter simply override the preexisting one but have no indication at present of the devel version. The previous way was to have the date and time in year-month-day-time format in the about screen. That method also has the advantage that the zips can be stored and will stay in sequence.
vellum
How do I do this (run......) and where is it documented? vellum
----- Original Message ----- From: "bulia byak" <buliabyak@...400...> To: "vellum" <kaver@...68...> Cc: "Bryce Harrington" <bryce@...260...>; "MenTaLguY" <mental@...3...>; "Kees Cook" <inkscape@...62...>; inkscape-devel@lists.sourceforge.net Sent: Friday, December 03, 2004 12:11 PM Subject: Re: [Inkscape-devel] Winlibre and Upping our point release numbers
I agree with this and in fact it was being done in the "early" days last year :-) but it suddenly stopped (why?).
Run
inkscape --version
to see the build date.
On Fri, Dec 03, 2004 at 12:19:38AM -0500, bulia byak wrote:
and where is it documented?
in 'man inkscape'
Actually... it's missing from the pod docs. It's listed in
inkscape --help
though. I've updated the pod now.
And, the man page is visible online too:
http://www.inkscape.org/doc/inkscape-man.html
bulia, I love the succinctness of the messages but I'm finding them less than helpful. When you talk of command line are you in the operating system or is there a command line set-up in Inkscape itself? In the former I can get down to my Inkscape folder and when I run "inkscape --version" it does not recognise this as a command. I am not very experienced with command line stuff, but willing to learn. vellum
----- Original Message ----- From: "bulia byak" <buliabyak@...400...> To: "vellum" <kaver@...68...> Cc: "Bryce Harrington" <bryce@...260...>; "MenTaLguY" <mental@...3...>; "Kees Cook" <inkscape@...62...>; inkscape-devel@lists.sourceforge.net Sent: Friday, December 03, 2004 4:19 PM Subject: Re: [Inkscape-devel] Winlibre and Upping our point release numbers
On Fri, 3 Dec 2004 16:14:08 +1100, vellum <kaver@...68...> wrote:
How do I do this (run......)
on the command line
and where is it documented?
in 'man inkscape'
bulia, I love the succinctness of the messages but I'm finding them less than helpful. When you talk of command line are you in the operating system or is there a command line set-up in Inkscape itself? In the former I can get down to my Inkscape folder and when I run "inkscape --version" it does not recognise this as a command. I am not very experienced with command line stuff, but willing to learn.
On my Windows 98, it's called "MS-DOS window" in the Start menu. Run it and use DOS commands to navigate to a dir and/or run a command. I have no idea if this is different on XP; others please provide more XP-specific info.
bulia, I love the succinctness of the messages but I'm finding them less
than
helpful. When you talk of command line are you in the operating
system
or is
there a command line set-up in Inkscape itself? In the former I can
get
down
to my Inkscape folder and when I run "inkscape --version" it does
not
recognise this as a command. I am not very experienced with command
line
stuff, but willing to learn.
On my Windows 98, it's called "MS-DOS window" in the Start menu. Run it and use DOS commands to navigate to a dir and/or run a command. I have no idea if this is different on XP; others please provide more XP-specific info.
On XP it's the "Command Prompt" under Start>All Programs>Accessories.
However, when I tried the --version flag it didn't launch inkscape (or return any info to the command prompt)... if I do it with -version it launches at least, but gives no version info. Any thoughts?
Does it work for you on 98 Bulia?
-Josh
Joshua A. Andler wrote:
bulia, I love the succinctness of the messages but I'm finding them less
than
helpful. When you talk of command line are you in the operating
system
or is
there a command line set-up in Inkscape itself? In the former I can
get
down
to my Inkscape folder and when I run "inkscape --version" it does
not
recognise this as a command. I am not very experienced with command
line
stuff, but willing to learn.
On my Windows 98, it's called "MS-DOS window" in the Start menu. Run it and use DOS commands to navigate to a dir and/or run a command. I have no idea if this is different on XP; others please provide more XP-specific info.
On XP it's the "Command Prompt" under Start>All Programs>Accessories.
However, when I tried the --version flag it didn't launch inkscape (or return any info to the command prompt)... if I do it with -version it launches at least, but gives no version info. Any thoughts?
Does it work for you on 98 Bulia?
-Josh
SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Actually, the old mechanism that we had, of being able to insert the version info into the svg doc in About was nice. Maybe we could work something out, such the About dialog inserting a text node into the doc; or even easier, have an xlink to a dynamically-made small svg with the info?
Or simplest of all, display it on the About window's dragbar?
Bob
I am still niggling away at trying to get version information using command line options. I just cannot get anything using '-version' '-v' '-V' 'V' '-version,' 'VERSION' or any other combination so far. I can get Inkscape to start or simply to return to the command line but nothing else. I am using Win 2000. Has anyone succeeded using Win2000 or XP (Josh has not). And bulia, do you get it to work with win98? If so what specific command are you using?
vellum
---- Original Message ----- From: "bulia byak" <buliabyak@...400...> To: "vellum" <kaver@...68...> Cc: "Bryce Harrington" <bryce@...260...>; "MenTaLguY" <mental@...3...>; "Kees Cook" <inkscape@...62...>; inkscape-devel@lists.sourceforge.net Sent: Friday, December 03, 2004 4:56 PM Subject: Re: [Inkscape-devel] Winlibre and Upping our point release numbers
bulia, I love the succinctness of the messages but I'm finding them less than helpful. When you talk of command line are you in the operating system
or is
there a command line set-up in Inkscape itself? In the former I can get
down
to my Inkscape folder and when I run "inkscape --version" it does not recognise this as a command. I am not very experienced with command line stuff, but willing to learn.
On my Windows 98, it's called "MS-DOS window" in the Start menu. Run it and use DOS commands to navigate to a dir and/or run a command. I have no idea if this is different on XP; others please provide more XP-specific info.
On Wed, 15 Dec 2004 23:11:50 +1100, vellum <kaver@...68...> wrote:
Win 2000. Has anyone succeeded using Win2000 or XP (Josh has not). And bulia, do you get it to work with win98? If so what specific command are you using?
Apparently it then starts a new DOS box, prints its stuff there, and closes. That's why you see nothing. But you can catch the output into a file:
inkscape --version > temp_file
and the temp_file will have the output. I just tried that and it works in win98. Though the version it reports for the latest build is 0.39CVS :(( Something is way behind in windows builds apparently.
thanks bulia. Ah. The marvels of DOS. Who'd a thunkit?
inkscape --version >tempfile does indeed work for win2000. The output is 'Inkscape 0.40 (Nov 30 2004). This is correct since it came from the full win32 release.
but...I do most of my work on the cvs versions, only downloading the latest inkscape_stripped_exe files. The version data in these are not changing and are wrong. I have checked three of them and they all come up with Inkscape 0.39cvs (Nov 19 2004). Even if this was 0.40 it is of no help for cvs versions. We need the full date number eg 0412161007. Windows builders? The frustrating thing is that we had it in the About box for a while and it worked perfectly. I doubt that anybody wants to have to go through command line stuff to get that information. Ah. Those halcyon days long gone.
vellum
----- Original Message ----- From: "bulia byak" <buliabyak@...400...> To: "vellum" <kaver@...68...> Cc: "Bryce Harrington" <bryce@...260...>; "MenTaLguY" <mental@...3...>; "Kees Cook" <inkscape@...62...>; inkscape-devel@lists.sourceforge.net Sent: Wednesday, December 15, 2004 11:21 PM Subject: Re: [Inkscape-devel] Winlibre and Upping our point release numbers
On Wed, 15 Dec 2004 23:11:50 +1100, vellum <kaver@...68...> wrote:
Win 2000. Has anyone succeeded using Win2000 or XP (Josh has not). And bulia, do you get it to work with win98? If so what specific command are
you
using?
Apparently it then starts a new DOS box, prints its stuff there, and closes. That's why you see nothing. But you can catch the output into a file:
inkscape --version > temp_file
and the temp_file will have the output. I just tried that and it works in win98. Though the version it reports for the latest build is 0.39CVS :(( Something is way behind in windows builds apparently.
On Thu, 2 Dec 2004, Kees Cook wrote:
Date: Thu, 2 Dec 2004 21:52:11 -0800 From: Kees Cook <inkscape@...62...> To: inkscape-devel@lists.sourceforge.net Subject: Re: [Inkscape-devel] Winlibre and Upping our point release numbers
On Thu, Dec 02, 2004 at 08:11:12PM -0500, bulia byak wrote:
inkscape --version
to see the build date.
I'd like to get this into the About page too. If nothing more, just a label widget at the bottom, like the status bar.
It is important that the version number or build date be in the About dialog but if it is being put there for ordinary users then they need the option to cut and paste that information (currently the about dialog text cannot be cut/copied and pasted which is a little annoying).
Could the lovely artwork in some way be combined with the new stock GtkAbout dialog (much like the GnomeAbout dialog only in Gtk since 2.4 i think)? Standard widgets could make things easier.
- Alan
Alan Horkan wrote:
It is important that the version number or build date be in the About dialog but if it is being put there for ordinary users then they need the option to cut and paste that information (currently the about dialog text cannot be cut/copied and pasted which is a little annoying).
Could the lovely artwork in some way be combined with the new stock GtkAbout dialog (much like the GnomeAbout dialog only in Gtk since 2.4 i think)? Standard widgets could make things easier.
- Alan
Currently, the About dialog is just an SVG viewer with the doc on it.
However, I have found that it is very easy to wrap the sp_svg_view thingy with a GtkMM widget, and use it in conjunction with other widgets. It is how the svg preview is done on the file dialog. Maybe someone could make the About window a GtkMM thing (which needs to be done anyway), with the artwork on top, and a text field with the info on the bottom.
The filedialog.cpp file is an example of how to wrap an svg viewer in GtkMM stuff.
Bob
El vie, 03-12-2004 a las 10:58 -0600, Bob Jamison escribió:
Alan Horkan wrote:
It is important that the version number or build date be in the About dialog but if it is being put there for ordinary users then they need the option to cut and paste that information (currently the about dialog text cannot be cut/copied and pasted which is a little annoying).
Could the lovely artwork in some way be combined with the new stock GtkAbout dialog (much like the GnomeAbout dialog only in Gtk since 2.4 i think)? Standard widgets could make things easier.
- Alan
Currently, the About dialog is just an SVG viewer with the doc on it.
However, I have found that it is very easy to wrap the sp_svg_view thingy with a GtkMM widget, and use it in conjunction with other widgets. It is how the svg preview is done on the file dialog. Maybe someone could make the About window a GtkMM thing (which needs to be done anyway), with the artwork on top, and a text field with the info on the bottom.
The filedialog.cpp file is an example of how to wrap an svg viewer in GtkMM stuff.
[ego mode on] Yeah, and put the names of the translators in too, just like gnome does. [ego mode off]
Cheers,
On Fri, Dec 03, 2004 at 06:05:59PM +0100, Lucas Vieites wrote:
Yeah, and put the names of the translators in too, just like gnome does.
Yup, I recommended this in the RFE or Bug that talks about the About box. I can't find it now, though. I had seen Scribus's About dialog with it's tabs, etc. I wanted to show the translators like they do.
On Fri, 3 Dec 2004, Lucas Vieites wrote:
Currently, the About dialog is just an SVG viewer with the doc on it.
However, I have found that it is very easy to wrap the sp_svg_view thingy with a GtkMM widget, and use it in conjunction with other widgets. It is how the svg preview is done on the file dialog. Maybe someone could make the About window a GtkMM thing (which needs to be done anyway), with the artwork on top, and a text field with the info on the bottom.
The filedialog.cpp file is an example of how to wrap an svg viewer in GtkMM stuff.
[ego mode on] Yeah, and put the names of the translators in too, just like gnome does. [ego mode off]
I'd like to echo this request - I'd like to see the translators represented in the about dialog as well. They're making very important contributions so I think they should be recognized. (Ditto for tutorial writers.)
Bryce
On Thu, Dec 02, 2004 at 07:27:44PM -0500, MenTaLguY wrote:
Don't forget that we actually did that for 0.39.1.
Yeah, but it was "surprising" because not everyone understands there is a hidden ".0". If we explicitly call it out, it's less of a surprise when/if we do fixes, but it's less marketable, since the world likes "1.0", "9.0", "1.7"... etc
However, I do tend to agree with bulia that it'd be best to avoid an 0.40.1 release specifically, because of existing strong expectations about 0.41 and confusion about how we do our version numbering right now.
Good point. What about doing 0.41 and 0.41.0?
On Thu, 2 Dec 2004, jon wrote:
Date: Thu, 2 Dec 2004 16:44:50 -0500 From: jon <jon@...235...> To: inkscape-devel@lists.sourceforge.net Subject: [Inkscape-devel] Winlibre and Upping our point release numbers
Man, reading these comments is fun. Did you all see that we are being included in this interesting collection of apps for windows users?
http://www.winlibre.com/en/Versions.php
Also check the numbers...I think I'm in favor of beginning to advance our version numbers higher up like firefox did, thunderbird, and gimp. Although numbering is quite superficial, maybe we should start doing full point release releases after 0.40. Maybe the next one is 0.50, then next 0.60, etc. (HINT: I'm working on the roadmap rework right now)
I like version numbers and I would particularly like to see something stamped as "1.0 stable" (because 1.0 is a very big deal to some users myself included) sometime in the next two years but I wouldn't recommend making the numbering system too arbitrary.
What might work would be to tag CVS and bump the version number more often like after a fix or new feature has been applied and things seem reasonable stable and buildable. This could be done without making a fullscale release, and more importantly it could be done often (on a timescale of weeks) and it would provide a jumping on point for those who want cutting edge but not bleeding edge.
It was roughly four months between Inkscape 0.40 and the previous version, which is perfectly reasonable and as inkscape does provide a wealth of nightly builds I couldn't really make claim that Inkscape does anything but live up to the maxim of "release early release often" but I do think tagging CVS more often even adding an additional minor number (like version 0.40.1) might be a reasonable way to sort of release more often.
However, our system works currently, so why change it, right? I do think though that we need to get a supa-advanced version of Inkscape out the gate as Microsoft is going to drop their WVG (their SVG makeover) soon, and then we know what that means...
It seems likely they will release Creature House Expression to fill this space, I recall it being mentioned (here i think) as a free download if you were willing to subject yourself to Microsoft Passport (which I wasn't so I never tried it).
I keep seeing in comments people saying how our app is very well developed for such an early release thus implying that the app is new. The public perceives an app through maturity on many levels. What do you all think?
I think users were comparing Inkscape to other open source applictions and that Windows and Mac users would not be so generous but that is not to say I dont think Inkscape is great and enjoy using it a lot, just that it it is important to carefully manage expectations or else users maybe dissappointed when 1.0 doesn't match what the old versions of the roadmap might have suggested it would be.
Sincerely
Alan Horkan
On Thu, 2 Dec 2004, jon wrote:
I keep seeing in comments people saying how our app is very well developed for such an early release thus implying that the app is new. The public perceives an app through maturity on many levels. What do you all think?
It's nice having a <1.00 number since that sets expectations in our favor, but I'd certainly support jumping towards 1.00 faster if it'd gain us benefits.
Given that we take 2-4 months between releases, even if we jumped by .1 each time, that'd still put a 1.00 release a couple years away, which "feels" like the right timeframe to me...
Bryce
On Thu, 2004-12-02 at 16:23 -0800, Bryce Harrington wrote:
On Thu, 2 Dec 2004, jon wrote:
I keep seeing in comments people saying how our app is very well developed for such an early release thus implying that the app is new. The public perceives an app through maturity on many levels. What do you all think?
It's nice having a <1.00 number since that sets expectations in our favor, but I'd certainly support jumping towards 1.00 faster if it'd gain us benefits.
Given that we take 2-4 months between releases, even if we jumped by .1 each time, that'd still put a 1.00 release a couple years away, which "feels" like the right timeframe to me...
Yeah, maybe the more important task at hand is to do what our mission says which is to be a SVG compliant editor. Maybe the more important thinking is that (and maybe we can loosely agree to this):
0.50 would be SVG Tiny (this is a general thinking overall thing)
1.0 would be full SVG 1.2 compliancy (both rendering and editing)
I have to admit though, 2 years away is a long time to get to our main goal (as stated in our mission on the front page of the site). As I keep learning from people whom are not in our community, the public at large does not care about all this jargon and point release systems, etc., for joe public to use Inkscape, the tool probably has to be >= 1.0 as big software companies have advertised their products as being, and Inkscape would need publicity and stability.
I'm talking generally here, but hey, it feels like time to zoom out and think about where this project is heading.
Also, somehow Firefox and Thunderbird went from 0.4/0.5 to 1.0 in around a year, and they both seem fairly stable. Although, they do have quite a few more developers on each team, right?
Jon
SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Thu, 2 Dec 2004, Jon Phillips wrote:
Date: Thu, 02 Dec 2004 15:55:31 +0000 From: Jon Phillips <jon@...235...> To: Bryce Harrington <bryce@...260...> Cc: inkscape inkscape-devel@lists.sourceforge.net Subject: Re: [Inkscape-devel] Winlibre and Upping our point release numbers
On Thu, 2004-12-02 at 16:23 -0800, Bryce Harrington wrote:
On Thu, 2 Dec 2004, jon wrote:
I keep seeing in comments people saying how our app is very well developed for such an early release thus implying that the app is new. The public perceives an app through maturity on many levels. What do you all think?
It's nice having a <1.00 number since that sets expectations in our favor, but I'd certainly support jumping towards 1.00 faster if it'd gain us benefits.
Given that we take 2-4 months between releases, even if we jumped by .1 each time, that'd still put a 1.00 release a couple years away, which "feels" like the right timeframe to me...
Yeah, maybe the more important task at hand is to do what our mission says which is to be a SVG compliant editor. Maybe the more important thinking is that (and maybe we can loosely agree to this):
I have to admit though, 2 years away is a long time to get to our main goal (as stated in our mission on the front page of the site). As I keep learning from people whom are not in our community, the public at large does not care about all this jargon and point release systems, etc., for joe public to use Inkscape, the tool probably has to be >= 1.0 as big software companies have advertised their products as being, and Inkscape would need publicity and stability.
0.50 would be SVG Tiny (this is a general thinking overall thing)
this and a few carefully chosen features (possibly leaving out a few things) could be called 1.0 (perhaps not so soon but somewhere in 0.5x releases)
1.0 would be full SVG 1.2 compliancy (both rendering and editing)
and this could be 2.0.
it all depends on if the developers agree that a stable 1.0 realease is important to some users as we think it is.
Sincerely
Alan Horkan
Free SVG Clip Art http://OpenClipArt.org Abiword is Awesome http://abisource.com
Jon Phillips wrote:
Yeah, maybe the more important task at hand is to do what our mission says which is to be a SVG compliant editor. Maybe the more important thinking is that (and maybe we can loosely agree to this):
0.50 would be SVG Tiny (this is a general thinking overall thing)
1.0 would be full SVG 1.2 compliancy (both rendering and editing)
Hmmm... since the spec is still not even final, I'm wondering a bit about the 1.2 targeting for 1.0. Perhaps 1.0 might target full SVG 1.1 support, then have 1.5 or 2.0 embrace SVG 2.0.
On Fri, 2004-12-03 at 09:20 -0800, Jon A. Cruz wrote:
Jon Phillips wrote:
Yeah, maybe the more important task at hand is to do what our mission says which is to be a SVG compliant editor. Maybe the more important thinking is that (and maybe we can loosely agree to this):
0.50 would be SVG Tiny (this is a general thinking overall thing)
1.0 would be full SVG 1.2 compliancy (both rendering and editing)
Hmmm... since the spec is still not even final, I'm wondering a bit about the 1.2 targeting for 1.0. Perhaps 1.0 might target full SVG 1.1 support, then have 1.5 or 2.0 embrace SVG 2.0.
Yes, that sounds more reasonable.
SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
participants (12)
-
Alan Horkan -
Bob Jamison -
Bryce Harrington -
bulia byak -
jon -
Jon A. Cruz -
Jon Phillips -
Joshua A. Andler -
Kees Cook -
Lucas Vieites -
MenTaLguY -
vellum