About version numbering schema
Locked
 
|
Hello,
I sent an email about that a few days ago, see here : http://mail.kde.org/pipermail/digikam-devel/2007-June/012932.html << Don't you think it's time to use a new version numbering schema ? I think digiKam has reached its stability point. For most people, when you see a 0.9.x version, it means the software is quite close to a stable 1.0 version. Using version 0.10 let digiKam looks as an immature software that lacks reliability and features. And I definitively think it's not the case ! Creating a 1.0 version would put digiKam under spotlight and that would be great... I also think it's important to clearly separate kde3 versions and kde4 version. This is why I make the following proposal : - create a 1.0.0 for the next digiKam version (instead of 0.9.2) 0.9.3 would be 1.0.1 - use 2.0 for kde4 port >> Achim and Mikolaj already said they like the idea. What about others ? Gilles, Marcel, Oliver, Arnd, ... ? Maybe you missed it in the thread :) -- Fabien _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
Re: About version numbering schema
|
|
2007/6/15, Fabien <[hidden email]>: GillesHello, this is not my viewpoint, but i'm developper. For me these features are important for photograph : XMP is not yet supported. No batch Queue manager. No search based on advanced metadata. No DB/pictures backup/restore tool. No versionning of pictures. Creating a 1.0 version would put digiKam under spotlight and that would sure... I also think it's important to clearly separate kde3 versions and kde4 agree for this point. This is why I make the following proposal : For 0.9.2 it's too late because all is ready to perform release and we have already don beta1, beta2 and beta3. We cannot break this serie. 0.9.3 would be 1.0.1 The discussion is open. Why not 1.0.0 , but i'm not alone to decide... - use 2.0 for kde4 port why not. _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
Re: About version numbering schema
|
|
On Fri, 15 Jun 2007, Gilles Caulier wrote:
[...] > 0.9.3 would be 1.0.1 > > The discussion is open. Why not 1.0.0, but i'm not alone to decide... Well, personally I think that it would be good to address a quite bunch of the bugs on the BKO before daring to go to 1.0. Best, Arnd _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
Re: About version numbering schema
|
|
2007/6/15, Arnd Baecker <[hidden email]>: On Fri, 15 Jun 2007, Gilles Caulier wrote: Yes, totally agree... Gilles _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
Re: About version numbering schema
|
|
In reply to this post by Fabien-5
Hmmm,
i can't see much wrong on the old schema... We have a list of features, that should be in 1.0. So this means, that 1.0 will be our major release and it will be available for KDE 4. That's fine for me. Most users gets digiKam trough their distribution and so they don't have to care which versions are comatible with KDE versions. All others should read release notes. But i'm only a translator and so it's not my point to decide Oliver Fabien schrieb: > Hello, > > I sent an email about that a few days ago, see here : > http://mail.kde.org/pipermail/digikam-devel/2007-June/012932.html > > << > Don't you think it's time to use a new version numbering schema ? > > I think digiKam has reached its stability point. > For most people, when you see a 0.9.x version, it means the software is > quite close to a stable 1.0 version. > Using version 0.10 let digiKam looks as an immature software that lacks > reliability and features. And I definitively think it's not the case ! > > Creating a 1.0 version would put digiKam under spotlight and that would > be great... > I also think it's important to clearly separate kde3 versions and kde4 > version. > > This is why I make the following proposal : > > - create a 1.0.0 for the next digiKam version (instead of 0.9.2) > 0.9.3 would be 1.0.1 > > - use 2.0 for kde4 port > >> > > Achim and Mikolaj already said they like the idea. > > What about others ? > Gilles, Marcel, Oliver, Arnd, ... ? > > Maybe you missed it in the thread :) > > -- > Fabien > > _______________________________________________ > Digikam-devel mailing list > [hidden email] > https://mail.kde.org/mailman/listinfo/digikam-devel > > Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
Re: About version numbering schema
|
|
I'm totally agre with you Oliver (:=)))
Gilles 2007/6/15, Oliver Dörr <[hidden email]>: Hmmm, _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
Re: About version numbering schema
|
|
In reply to this post by Gilles Caulier-4
Dnia sobota 16 czerwiec 2007, Gilles Caulier napisał:
> 2007/6/15, Fabien <[hidden email]>: > > Hello, > > > > I sent an email about that a few days ago, see here : > > http://mail.kde.org/pipermail/digikam-devel/2007-June/012932.html > > > > << > > Don't you think it's time to use a new version numbering schema ? > > I think digiKam has reached its stability point. > > For most people, when you see a 0.9.x version, it means the software > > is quite close to a stable 1.0 version. > > Using version 0.10 let digiKam looks as an immature software that > > lacks reliability and features. And I definitively think it's not the > > case ! > > this is not my viewpoint, but i'm developper. For me these features are > important for photograph : With this attitude there will be always new things to include :) > XMP is not yet supported. Make it really simple (as newest XnView): just let read unsolved XML in separate tab. > No batch Queue manager. Wait for KDE4 and promised tools for recording (although I didn't read anything new about them lately). > No search based on advanced metadata. > No DB/pictures backup/restore tool. > No versionning of pictures. That is big feature. Implementing it properly may take really long time... You know, from myself I could add several points: - multiuser, networked database for work eg. in small photo agency - support for archiving on various media (in Digikam store only thumbnails with localizations of real images) - scripting backend for more automation and better user expandability - service menus support - CD/DVD cover printing (both thumbnails and extended descriptions, basing on metadata, Digikam comments) - spread collection (not in one directory) - file system browsing - improved cropping (handling of borders, including rotation) - non reducting rotation :) m. _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
Re: About version numbering schema
|
|
On Sat, 16 Jun 2007, Mikolaj Machowski wrote:
> Dnia sobota 16 czerwiec 2007, Gilles Caulier napisał: > > 2007/6/15, Fabien <[hidden email]>: > > > Hello, > > > > > > I sent an email about that a few days ago, see here : > > > http://mail.kde.org/pipermail/digikam-devel/2007-June/012932.html > > > > > > << > > > Don't you think it's time to use a new version numbering schema ? > > > I think digiKam has reached its stability point. > > > For most people, when you see a 0.9.x version, it means the software > > > is quite close to a stable 1.0 version. > > > Using version 0.10 let digiKam looks as an immature software that > > > lacks reliability and features. And I definitively think it's not the > > > case ! It certainly does not lack reliability! Concerning features: well, there are quite a few high rated wishes in the B.K.O (Hmm: could not find any way to get the results of search in the B.K.O. sorted by rating, is there any?) Generally: - the workflow of tagging, - filtering of tags, rating, ... - searches (related to the previous) requires a lot of thought and (then) improvement. Going to 1.0 raises the level of what people expect ("oh, still not as good as ..."), while a number <1.0 makes people more relaxed about things... Well, apart from this, I personally don't care too much about version numbers. Much more important is the list of points you raise below! > > this is not my viewpoint, but i'm developper. For me these features are > > important for photograph : > > With this attitude there will be always new things to include :) I like this attitude ;-) > > XMP is not yet supported. > > Make it really simple (as newest XnView): just let read unsolved XML in > separate tab. > > > No batch Queue manager. > > Wait for KDE4 and promised tools for recording (although I didn't read > anything new about them lately). > > > No search based on advanced metadata. > > No DB/pictures backup/restore tool. all very important! > > No versionning of pictures. > > That is big feature. Implementing it properly may take really long > time... It also depends on how it is implemented: For example in http://bugs.kde.org/show_bug.cgi?id=103350 there is a patch to provide simple "versioning", by just keeping a hidden copy of old versions ... (well, I don't like that, because I prefer if the user consciously decides which files to keep and which not...) And then there is (in the same BKO) the discussion of action lists to save modifications of an image in terms of the actions to be used instead of the actual modified images. However, I have to admit, that I am always a bit sceptical, when too many features are added, which go in the direction of image editing ... Personally I would prefer if F4 could bring up krita in a specialized mode, so that it interconnects with digikam and only a photograph related subset of menus is available. Then of course krita would need to store the actions to modifiy an image in some way (Unfortunately, this would be a much more complicated project than action lists on the digikam level alone ...) > You know, from myself I could add several points: Mikolaj, these are all very important, some of them are not yet registered in the B.K.O! (while I am currently on the quest of reducing the number of BKO entries, here it would be great if you could add the new points! ;-) > - multiuser, networked database for work eg. in small photo agency > - support for archiving on various media (in Digikam store only > thumbnails with localizations of real images) > - scripting backend for more automation and better user expandability With KDE4 I would hope for a tight integration of KROSS http://kross.dipe.org/ > - service menus support I agree. While one can use the .desktop files to get additional stuff into the right-click menu, it would be nice to have additional entries in one of the menus (so that for example also a shortcut can be associated). Well, it's all discussed here http://bugs.kde.org/show_bug.cgi?id=88932 and should not be too difficult to implement ... > - CD/DVD cover printing (both thumbnails and extended descriptions, > basing on metadata, Digikam comments) > - spread collection (not in one directory) > - file system browsing Yes, this would be nice! > - improved cropping (handling of borders, including rotation) Oh, yes, rotation, that would be good, indeed! What do you mean by "handling of borders"? (Well, first we have to get the aspect ratio cropping working correctly at all, see http://bugs.kde.org/show_bug.cgi?id=128293 ) > - non reducting rotation Sorry, what does this mean? Best, Arnd _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
Re: About version numbering schema
|
|
Dnia sobota 16 czerwiec 2007, Arnd Baecker napisał:
> > Going to 1.0 raises the level of what people expect > ("oh, still not as good as ..."), while a number <1.0 > makes people more relaxed about things... And with number <1.0 you cannot propose to use program in some environments (yes, we know this is bullshit but that's the world we live in). > It also depends on how it is implemented: > For example in http://bugs.kde.org/show_bug.cgi?id=103350 > there is a patch to provide simple "versioning", > by just keeping a hidden copy of old versions ... > (well, I don't like that, because I prefer > if the user consciously decides which files to keep and which not...) Don't like that because HD usage will skyrocket. Even with contemporary prices of storage this will be painful. Also I hope for something like history editor with possibility to edit or turn off some effects from image history of editing. > > You know, from myself I could add several points: > > Mikolaj, these are all very important, some of them > are not yet registered in the B.K.O! > (while I am currently on the quest of reducing the number of BKO Noble task :) > entries, here it would be great if you could add the new points! ;-) OK. > > Oh, yes, rotation, that would be good, indeed! > What do you mean by "handling of borders"? At the moment you can resize crop area only by corners. It would be nice if you could grab any border in any place to resize (eg. good for resize of crop on big images with full 100% zoom or greater), possibility to rotate crop area on image like in Photoshop, not two step action (crop, free rotation). > > - non reducting rotation > > Sorry, what does this mean? When you have picture 100x100 pixels and you will rotate it 45 degrees Digikam forces you to reduce image to fit in original canvas of 100x100 pixels. In effect real image is reduced to ca. 70x70 pixels. Instead canvas should be increased to ca. 140x140 pixels to accommodate original image in full size. m. _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
«
Return to digikam-devel
|
1 view|%1 views
| Free forum by Nabble | Edit this page |