Hello All,
A while ago, there was a discussion about the numbering of the next release. "0.49" doesn't exactly instill confidence in the completeness of the application. On the other hand, "1.0" could be misleading with respect to svg compliance. Other ideas were to use a date-based system "2013.10" or something.
Any thoughts?
AV
2013/10/18 Alex Valavanis <valavanisalex@...400...>:
Hello All,
A while ago, there was a discussion about the numbering of the next release. "0.49" doesn't exactly instill confidence in the completeness of the application. On the other hand, "1.0" could be misleading with respect to svg compliance. Other ideas were to use a date-based system "2013.10" or something.
This was discussed some time ago, but there didn't seem to be any consensus.
I think that full support of the SVG 1.0 standard is somewhat unrealistic to achieve in the near future, and it's hard to say what exactly "support" means in the case of Inkscape. For instance, we respect the clip-rule property but there's no way to set it - is this "support" or not?
If we use a date-based system, we lose a simple way to tell users that a given release constitutes a bigger change.
The real solution would be to change the roadmap, so that 1.0 is not tied to support for SVG 1.0.
I think we can call Inkscape "1.0" once the following two things are fixed: 1. Flowtext has an SVG-compliant fallback in a svg:switch, 2. Default document coordinates match default SVG coordinates.
Regards, Krzysztof
On Fri, 2013-10-18 at 12:05 +0200, Krzysztof Kosiński wrote:
I think we can call Inkscape "1.0" once the following two things are fixed:
- Flowtext has an SVG-compliant fallback in a svg:switch,
- Default document coordinates match default SVG coordinates.
These are very reasonable goals for a 1.0 release.
If there's consensus on the items, we could easily create a series and apply some bugs and/or blueprints to them so the roadmap is clear.
Martin,
2013/10/18 Martin Owens <doctormo@...400...>:
These are very reasonable goals for a 1.0 release.
If there's consensus on the items, we could easily create a series and apply some bugs and/or blueprints to them so the roadmap is clear.
I added the Inkscape 1.0 milestone in Launchpad and added those two bugs to it.
Regards, Krzysztof
2013/10/18 Alexandre Prokoudine <alexandre.prokoudine@...400...>:
On Fri, Oct 18, 2013 at 2:05 PM, Krzysztof Kosiński wrote:
If we use a date-based system, we lose a simple way to tell users that a given release constitutes a bigger change.
How so?
Let's say we have Inkscape 2.10.
If the next version is 2.12, it sends the implicit message "this is an incremental update".
If the next version is 3.0, it sends the implicit message "this is a totally new version which changes lots of things".
Regards, Krzysztof
On Fri, Oct 18, 2013 at 7:42 PM, Krzysztof Kosiński wrote:
On Fri, Oct 18, 2013 at 2:05 PM, Krzysztof Kosiński wrote:
If we use a date-based system, we lose a simple way to tell users that a given release constitutes a bigger change.
How so?
Let's say we have Inkscape 2.10.
How is it even remotely date based?
2014.0 - now that is date based. 2014.2 - obviously incremental release with less changes. 2015.0 - brand new release again.
So no, I don't get our point :)
Alexandre
2013/10/18 Alexandre Prokoudine <alexandre.prokoudine@...400...>:
How is it even remotely date based?
2014.0 - now that is date based. 2014.2 - obviously incremental release with less changes. 2015.0 - brand new release again.
So no, I don't get our point :)
My example was not date-based, I just wanted to illustrate something which is not possible in a strictly date-based scheme.
Your proposed scheme is actually a hybrid. I thought that by "date-based" we mean something like Ubuntu versioning: YY.MM, not YYYY.V where V is the minor version number.
Regards, Krzysztof
On Fri, Oct 18, 2013 at 7:53 PM, Krzysztof Kosiński wrote:
Your proposed scheme is actually a hybrid. I thought that by "date-based" we mean something like Ubuntu versioning: YY.MM, not YYYY.V where V is the minor version number.
Either is fine with me. So is releasing v1.0.
My point is that date-based releases a pretty common by now even in proprietary world, and they don't impose any of the 1.0=stable sillyness.
Alexandre
On Fri, 2013-10-18 at 17:53 +0200, Krzysztof Kosiński wrote:
Your proposed scheme is actually a hybrid. I thought that by "date-based" we mean something like Ubuntu versioning: YY.MM, not YYYY.V where V is the minor version number.
Ubuntu has point releases. 12.04.4 is due out soonish.
Martin,
participants (4)
-
Alex Valavanis -
Alexandre Prokoudine -
Krzysztof Kosiński -
Martin Owens