1:44 a.m.
Hi,
This mail can lead to all sorts of flamewars, hunting with pitchforks
etc., but what the hell... :)
Don't know for you, but to me Inkscape seems to be inside the <1.0
loop forever, whereas people all around effectively use it for solving
Real Life (C)(R)(tm) tasks. Yes, it is unbearably slow, it cannot work
as a standalone prepress tool and so on and so forth. Nevertheless,
it's real tool, not toy.
That is, in a way the current <1.0 versioning quite misrepresents
Inkscape and its features. Lately Hugin (which is a panorama making
tool) project adopted the YEAR.EVEN/ODD versioning scheme. Should we
probably discuss whether we need something like that?
This would be another way to deal with the roadmap that we don't
really follow anyway.
/me ducks
Alexandre
3:46 a.m.
2009/9/30 Alexandre Prokoudine <alexandre.prokoudine@...400...>:
That is, in a way the current <1.0 versioning quite misrepresents
Inkscape and its features. Lately Hugin (which is a panorama making
tool) project adopted the YEAR.EVEN/ODD versioning scheme. Should we
probably discuss whether we need something like that?
I think the date-based version scheme is boring :) and it doesn't tell
when important features are added.
The reason why there is no 1.0 is because 1.0 was intended to be a
milestone of full SVG 1.1 support, which we might never achieve. A
better approach would be to set more realistic major version
milestones.
Here are my candidates for major version milestones:
- fast Cairo based renderer
- hardware acceleration using OpenVG
- live vector effects replace Boolean operations, offset, etc.
- rich text support (e.g. hyphenation, subscript and superscript,
paragraphs, underlines) in the text tool
- basic animation
Regards, Krzysztof
6:39 a.m.
On Wed, 2009-09-30 at 20:46 +0200, Krzysztof Kosiński wrote:
2009/9/30 Alexandre Prokoudine
<alexandre.prokoudine@...400...>:
> That is, in a way the current <1.0 versioning quite misrepresents
> Inkscape and its features. Lately Hugin (which is a panorama making
> tool) project adopted the YEAR.EVEN/ODD versioning scheme. Should we
> probably discuss whether we need something like that?
I think the date-based version scheme is boring :) and it doesn't tell
when important features are added.
The reason why there is no 1.0 is because 1.0 was intended to be a
milestone of full SVG 1.1 support, which we might never achieve.
If we never achieve full 1.1 support I think I'll shoot myself.
Seriously, if we are limiting ourselves to the SVG standard, yet no one
is pushing to achieve it, what is the point of that limitation?
Perhaps we should make it mandatory that at least 1 of our SoC spots
each year goes toward implementing some piece needed to be more
compliant. It's not fun, it's not exciting, it's not really glamorous
either, but it will push that major project goal forward.
Cheers,
Josh
6:58 a.m.
-----Original Message-----
From: Joshua A. Andler [mailto:scislac@...400...]
Sent: woensdag 30 september 2009 23:40
To: Krzysztof Kosiński
Cc: Inkscape Devel List; Alexandre Prokoudine
Subject: Re: [Inkscape-devel] versioning scheme
If we never achieve full 1.1 support I think I'll shoot myself.
Seriously, if we are limiting ourselves to the SVG standard,
yet no one is pushing to achieve it, what is the point of
that limitation?
Perhaps we should make it mandatory that at least 1 of our
SoC spots each year goes toward implementing some piece
needed to be more compliant. It's not fun, it's not exciting,
it's not really glamorous either, but it will push that major
project goal forward.
It can be fun. I've had fun making a couple of testsuite compliance tests pass.
There's quite a number of tests that fail; I found it quite rewarding when I could
turn one fail into a pass. http://home.hccnet.nl/th.v.d.gronde/inkscape/ResultViewer.html
One of the cool things is that it doesn't require UI-coding which is tedious at best.
No use cases, no discussions on what shortcuts you need, and no bugs from users that click
different than you do. Simply very well defined small/large projects :-)
I would really like to have this testresult website updated every day.
Just to bring it up on the list again: I think we reeeeaaalllly should get this website
updated regularly. I cannot offer hardware, hope someone else can.
Ciao,
Johan
8:14 p.m.
Wed, 30 Sep 2009 23:58:05 +0200
J.B.C.Engelen@...1578... kirjoitti:
It can be fun. I've had fun making a couple of testsuite
compliance
tests pass. There's quite a number of tests that fail; I found it
quite rewarding when I could turn one fail into a pass.
http://home.hccnet.nl/th.v.d.gronde/inkscape/ResultViewer.html One of
the cool things is that it doesn't require UI-coding which is tedious
at best. No use cases, no discussions on what shortcuts you need, and
no bugs from users that click different than you do. Simply very well
defined small/large projects :-)
I would really like to have this testresult website updated every
day. Just to bring it up on the list again: I think we reeeeaaalllly
should get this website updated regularly. I cannot offer hardware,
hope someone else can.
I could provide automatical daily updates. I looked into the test suite
and managed to run the test cases, but I can't figure out how I'm
supposet to set up that web frontend. Please provide instructions.
Besides, with all that javascript, the site takes quite a while to
render as it is. I'd suspect that when it's updated daily, the amount of
results grows fast and it'll become really big & slow page. IMO it
would be best to have a static, pre-built page. Hiding unchanged
results and displaying a couple most recent changes would be nice,
too. That's a whole another discussion, though.
--
Niko Kiirala
niko@...1267...
8:48 p.m.
-----Original Message-----
From: Niko Kiirala [mailto:niko@...1267...]
Sent: Thursday, October 01, 2009 13:15
To: inkscape-devel(a)lists.sourceforge.net
Subject: Re: [Inkscape-devel] versioning scheme
Wed, 30 Sep 2009 23:58:05 +0200
J.B.C.Engelen@...1578... kirjoitti:
> I would really like to have this testresult website updated
every day.
> Just to bring it up on the list again: I think we
reeeeaaalllly should
> get this website updated regularly. I cannot offer hardware, hope
> someone else can.
I could provide automatical daily updates. I looked into the
test suite and managed to run the test cases, but I can't
figure out how I'm supposet to set up that web frontend.
Please provide instructions.
This is great news!
I'm not an expert on setting up websites, but I'm sure
someone can help with that.
A solution could be to do the tests daily on your
machine, and automatically put that on a webpage
that is hosted where inkscape.org is hosted?
(i.e. the daily script would replace a file on
inkscape.org server).
I think the biggest problem at this moment is hardware.
Once we have a system running daily tests, it will not be hard
to find someone who likes to work on displaying the results on
a website with a fancy look :-)
(solution for the many 'new' testresults that are not really
new and that need manual intervention: use perceptualdiff)
Ciao,
Johan
9:16 p.m.
J.B.C.Engelen@...1578... wrote:
(solution for the many 'new' testresults that are not really
new and that need manual intervention: use perceptualdiff)
This is indeed a good point, and there are (were?) some problems with
perceptualdiff and transparency (it didn't take it into account when
comparing colors). So if you encounter any problems, I have a patch
lying around for an old version of perceptualdiff that should do the trick.
9:03 p.m.
Niko Kiirala wrote:
...
> I would really like to have this testresult website updated every
> day. Just to bring it up on the list again: I think we reeeeaaalllly
> should get this website updated regularly. I cannot offer hardware,
> hope someone else can.
I could provide automatical daily updates. I looked into the test suite
and managed to run the test cases, but I can't figure out how I'm
supposet to set up that web frontend. Please provide instructions.
That would be absolutely great. It's done using GWT and you can just
"compile" the project in gsoc-testsuite/ResultViewer and then upload the
result. It then expects the json output to be in the same directory. If
you need any help, just ask.
As for running the tests themselves, I think it should be fine under
Linux, but under Windows it is recommended to compile Inkscape as a
console application if you want to run the tests unattended (prevents
some, but still not all, dialog boxes in case of crashes).
Besides, with all that javascript, the site takes quite a while to
render as it is. I'd suspect that when it's updated daily, the amount of
results grows fast and it'll become really big & slow page. IMO it
would be best to have a static, pre-built page. Hiding unchanged
results and displaying a couple most recent changes would be nice,
too. That's a whole another discussion, though.
You are completely right. Originally I did it this way because I wanted
to try out some interactive stuff, but I never got around to that and
the amount of results is indeed quite large. Someone who is handy with
scripts might be able to create a simple script to analyze the json and
generate at least something similar to what is shown now (but restricted
to the last couple of weeks or something).
9:30 p.m.
2009/10/1 Jasper van de Gronde <th.v.d.gronde@...528...>:
You are completely right. Originally I did it this way because I
wanted
to try out some interactive stuff, but I never got around to that and
the amount of results is indeed quite large. Someone who is handy with
scripts might be able to create a simple script to analyze the json and
generate at least something similar to what is shown now (but restricted
to the last couple of weeks or something).
Python to the rescue!
http://docs.python.org/library/json.html
Then open an XHTML website template and merge the results in using DOM
manipulation.
http://docs.python.org/library/xml.dom.minidom.html
Regards, Krzysztof
1:26 p.m.
Thu, 01 Oct 2009 14:03:01 +0200
Jasper van de Gronde <th.v.d.gronde@...528...> kirjoitti:
That would be absolutely great. It's done using GWT and you can
just
"compile" the project in gsoc-testsuite/ResultViewer and then upload
the result. It then expects the json output to be in the same
directory. If you need any help, just ask.
Thanks, I managed to build the result viewer.
The site is now up at http://auriga.mine.nu/inkscape/
It _should_ update daily, showing the status of SVN trunk. If
everything works as it should, the results for today will appear in
approximately six hours.
--
Niko Kiirala
niko@...1267...
11:15 p.m.
Do we have any automatic build server?
I thought on sf there is something like this.
On that can run a "make rendertest" as well.
Adib.
---
2009/9/30 <J.B.C.Engelen@...1578...>:
> -----Original Message-----
> From: Joshua A. Andler [mailto:scislac@...400...]
> Sent: woensdag 30 september 2009 23:40
> To: Krzysztof Kosiński
> Cc: Inkscape Devel List; Alexandre Prokoudine
> Subject: Re: [Inkscape-devel] versioning scheme
>
> If we never achieve full 1.1 support I think I'll shoot myself.
> Seriously, if we are limiting ourselves to the SVG standard,
> yet no one is pushing to achieve it, what is the point of
> that limitation?
>
> Perhaps we should make it mandatory that at least 1 of our
> SoC spots each year goes toward implementing some piece
> needed to be more compliant. It's not fun, it's not exciting,
> it's not really glamorous either, but it will push that major
> project goal forward.
It can be fun. I've had fun making a couple of testsuite compliance tests pass.
There's quite a number of tests that fail; I found it quite rewarding when I could
turn one fail into a pass. http://home.hccnet.nl/th.v.d.gronde/inkscape/ResultViewer.html
One of the cool things is that it doesn't require UI-coding which is tedious at best.
No use cases, no discussions on what shortcuts you need, and no bugs from users that click
different than you do. Simply very well defined small/large projects :-)
I would really like to have this testresult website updated every day.
Just to bring it up on the list again: I think we reeeeaaalllly should get this website
updated regularly. I cannot offer hardware, hope someone else can.
Ciao,
Johan
------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
Inkscape-devel mailing list
Inkscape-devel(a)lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
12:30 a.m.
On Oct 1, 2009, at 7:15 AM, the Adib wrote:
Do we have any automatic build server?
I thought on sf there is something like this.
On that can run a "make rendertest" as well.
We should probably look into https://build.opensuse.org/
Also if someone wants to set up an automated build server, I'd
recommend CruiseControl.
7:15 a.m.
W dniu 30 września 2009 23:39 użytkownik Joshua A. Andler
<scislac@...400...> napisał:
If we never achieve full 1.1 support I think I'll shoot myself.
Seriously, if we are limiting ourselves to the SVG standard, yet no one
is pushing to achieve it, what is the point of that limitation?
I think that's a non sequitur. We limit ourselves to SVG so that other
programs might use drawings made with Inkscape. Even a program that
can only output paths is useful - the goal of complying with SVG is
not eventually supporting the entirety of it, but being compatible
with other SVG programs. Support for the entire SVG 1.1 specification
is important if we want to use Inkscape to edit files created with
other applications, but it doesn't affect the utility of Inkscape as a
content creation program.
A nice step towards SVG 1.1 compliance would be to put the rendering
tests in the trunk and integrate them with 'make check' (or 'waf
check', shortly). And fixing the unit tests so that they don't fail.
Regards, Krzysztof
8:36 a.m.
On Wed, 2009-09-30 at 20:44 +0400, Alexandre Prokoudine wrote:
That is, in a way the current <1.0 versioning quite misrepresents
Inkscape and its features. Lately Hugin (which is a panorama making
tool) project adopted the YEAR.EVEN/ODD versioning scheme. Should we
probably discuss whether we need something like that?
+1 I hate version numbers. Anything to make them go away makes me
happier.
--Ted
9:21 a.m.
On Wed, 2009-10-07 at 19:36 -0400, Ted Gould wrote:
On Wed, 2009-09-30 at 20:44 +0400, Alexandre Prokoudine wrote:
> That is, in a way the current <1.0 versioning quite misrepresents
> Inkscape and its features. Lately Hugin (which is a panorama making
> tool) project adopted the YEAR.EVEN/ODD versioning scheme. Should we
> probably discuss whether we need something like that?
+1 I hate version numbers. Anything to make them go away makes me
happier.
+1 I just went to the Hugin page to see that it was how I thought. I
really do like that scheme much better thank our current one.
11:07 a.m.
On Wed, 2009-10-07 at 17:21 -0700, Joshua A. Andler wrote:
On Wed, 2009-10-07 at 19:36 -0400, Ted Gould wrote:
> On Wed, 2009-09-30 at 20:44 +0400, Alexandre Prokoudine wrote:
> > That is, in a way the current <1.0 versioning quite misrepresents
> > Inkscape and its features. Lately Hugin (which is a panorama making
> > tool) project adopted the YEAR.EVEN/ODD versioning scheme. Should we
> > probably discuss whether we need something like that?
>
> +1 I hate version numbers. Anything to make them go away makes me
> happier.
+1 I just went to the Hugin page to see that it was how I thought. I
really do like that scheme much better thank our current one.
Let me clarify, I'd say YEAR.INCREMENTING_NUMBER_STARTING_AT_ZERO
7:27 a.m.
On Wed, Oct 07, 2009 at 07:07:58PM -0700, Joshua A. Andler wrote:
On Wed, 2009-10-07 at 17:21 -0700, Joshua A. Andler wrote:
> On Wed, 2009-10-07 at 19:36 -0400, Ted Gould wrote:
> > On Wed, 2009-09-30 at 20:44 +0400, Alexandre Prokoudine wrote:
> > > That is, in a way the current <1.0 versioning quite misrepresents
> > > Inkscape and its features. Lately Hugin (which is a panorama making
> > > tool) project adopted the YEAR.EVEN/ODD versioning scheme. Should we
> > > probably discuss whether we need something like that?
> >
> > +1 I hate version numbers. Anything to make them go away makes me
> > happier.
>
> +1 I just went to the Hugin page to see that it was how I thought. I
> really do like that scheme much better thank our current one.
>
Let me clarify, I'd say YEAR.INCREMENTING_NUMBER_STARTING_AT_ZERO
A compromise that retains but augments our current numbering scheme
could be:
YEAR.SVG_COMPLIANCE.INCREMENTAL_NUMBER
So for example, we'd have:
2008.0.46
2009.0.47
2010.0.48
2010.0.49
...
2010.1.00
Retains the same meaning and history of our current numbering scheme,
plus makes the leftmost number more appealing to the wider userbase.
(I'm just throwing this idea out there, not advocating for it; I've no
problems with our current numbering scheme, and am not really active
enough in development these days to warrant having an opinion. But hey,
unpainted bike shed!)
Bryce
4:54 p.m.
I agree with this, not only because it works in a clean and
unambiguous way,
but also because the Boss says so. This is clearly an Executive decision,
and it is the kind of ruling that Bryce is the right guy to make.
Easier than the
Solomon/baby thing, but still, he must deal with a bunch of ignorant
primadonnas like us. :-)
bob
On 10/9/2009 5:27 PM, Bryce Harrington wrote:
A compromise that retains but augments our current numbering scheme
could be:
YEAR.SVG_COMPLIANCE.INCREMENTAL_NUMBER
So for example, we'd have:
2008.0.46
2009.0.47
2010.0.48
2010.0.49
...
2010.1.00
Retains the same meaning and history of our current numbering scheme,
plus makes the leftmost number more appealing to the wider userbase.
(I'm just throwing this idea out there, not advocating for it; I've no
problems with our current numbering scheme, and am not really active
enough in development these days to warrant having an opinion. But hey,
unpainted bike shed!)
Bryce
10:25 a.m.
On Oct 7, 2009, at 7:07 PM, Joshua A. Andler wrote:
On Wed, 2009-10-07 at 17:21 -0700, Joshua A. Andler wrote:
> On Wed, 2009-10-07 at 19:36 -0400, Ted Gould wrote:
>> On Wed, 2009-09-30 at 20:44 +0400, Alexandre Prokoudine wrote:
>>> That is, in a way the current <1.0 versioning quite misrepresents
>>> Inkscape and its features. Lately Hugin (which is a panorama making
>>> tool) project adopted the YEAR.EVEN/ODD versioning scheme.
>>> Should we
>>> probably discuss whether we need something like that?
>>
>> +1 I hate version numbers. Anything to make them go away makes me
>> happier.
>
> +1 I just went to the Hugin page to see that it was how I thought. I
> really do like that scheme much better thank our current one.
>
Let me clarify, I'd say YEAR.INCREMENTING_NUMBER_STARTING_AT_ZERO
A year-based scheme is nice for marketing, but bad for programs.
One main point is that a major/minor scheme allows for compatibility.
Given that we are moving more and more to have plugins do more and
extending things, versioning is important.
We could have a separate API version and program version, but that
would really confuse users.
10:25 p.m.
On Fri, 2009-10-09 at 18:25 -0700, Jon A. Cruz wrote:
One main point is that a major/minor scheme allows for compatibility.
Given that we are moving more and more to have plugins do more and
extending things, versioning is important.
We could have a separate API version and program version, but that
would really confuse users.
I really think a separate plugin API makes some amount of sense in that
we probably wouldn't rev it every version. If we had only revision
plugin authors would have to change their plugin to recognize the new
release. I'm not sure that we can't make that understandable for users,
at least as understandable and an enumerated list of versions.
--Ted
1:20 a.m.
On Oct 10, 2009, at 6:25 AM, Ted Gould wrote:
I really think a separate plugin API makes some amount of sense in
that
we probably wouldn't rev it every version. If we had only revision
plugin authors would have to change their plugin to recognize the new
release. I'm not sure that we can't make that understandable for
users,
at least as understandable and an enumerated list of versions.
Ok. If you think that makes sense, then we can probably make it work.
As long as things are explicit, it sounds good. In hand with the app
version Bryce mentioned we can get a nice combo going.
4:50 a.m.
Was a consensus reached on doing a new versioning scheme?
I added 0.48, 0.49, etc. to launchpad for milestones, but can update
them to whatever is decided. Let me know.
Bryce
2:38 p.m.
On Thu, Oct 1, 2009 at 3:44 AM, Alexandre Prokoudine <
alexandre.prokoudine@...400...> wrote:
Ditto
-- Chris Morgan <chris.morganiser@...400...
I'm good at making two things: mistakes and enemies.
Hi,
Don't know for you, but to me Inkscape seems to be inside the <1.0
loop forever, whereas people all around effectively use it for solving
Real Life (C)(R)(tm) tasks. Yes, it is unbearably slow, it cannot work
as a standalone prepress tool and so on and so forth. Nevertheless,
it's real tool, not toy.
I quite agree with you, but personally I don't feel the same way about the
version numbers. 0.47 looks good to me, whereas 4.7 doesn't look as good,
and 47.0 doesn't look as good, and 2.3 doesn't look as good. 0.4.7 also
doesn't look as good. 0.47 looks nice :-)
That is, in a way the current <1.0 versioning quite misrepresents
Inkscape and its features.
Not sure about that. To me, I don't care much. But 0.47 makes me think
that there have been 47 releases (ignoring ones like 0.45.1)...
Lately Hugin (which is a panorama making
tool) project adopted the YEAR.EVEN/ODD versioning scheme. Should
we
probably discuss whether we need something like that?
I reckon that that's ugly. In my opinion you need to either go with
"Inkscape 2010" and only have one release per year, or do it like Ubuntu
does: "Inkscape 10.04" for a release next April. 2010.04, 2010.1, 2010-1.0,
none of them look as good.
This would be another way to deal with the roadmap that we don't
really follow anyway.
The roadmap is a useful thing though, even if you just stick in an "Expected
date of completion: July 2037"... currently I know that basic animation
support is coming in 0.48. I mean 0.49. I mean 0.50. I mean 0.51...
/me ducks
4964
days inactive
4992
days old
inkscape-devel@lists.inkscape.org
22 comments
12 participants
participants (12)
-
unknown＠example.com -
Alexandre Prokoudine -
Bob Jamison -
Bryce Harrington -
Chris Morgan -
Jasper van de Gronde -
Jon A. Cruz -
Joshua A. Andler -
Krzysztof Kosiński -
Niko Kiirala -
Ted Gould -
the Adib