[scribus-dev] What to do?

[Gregory Pittman]

On 02/25/2011 11:49 AM, Craig Bradney wrote:
> On 2/25/11 4:21 PM, a.l.e wrote:
>> hi
>>
>> my point of view...
>>
>>
>>> I have few improvements in my local Scribus 1.4 not published yet.
>>> I would like to ask you, which patches and for which Scribus version
>>> I should
>>> upload and in what order?
>>>
>>> * [Preflight Verifier] widows/orphans check
>> 1.4.1 + 1.5
>>
>>> * [Preflight Verifier] RGB text check
>>
>> 1.4.1 + 1.5
>>
>>> * [Preflight Verifier] progress bar indication during checking
>>
>> 1.5
>>
>>> * [Preflight Verifier] placing text cursor at CPos related to
>>> selected error
>>> item and automatically select whole paragraph for better visualition
>>> region of
>>> problem
>>
>> 1.4.1 + 1.5
>>
>>> * [ODT import] feature for omit whole paragraphs style information
>>> (any new
>>> styles are created, all text has Default Paragraph Style), but saving
>>> local
>>> character formatting
>>
>> 1.4.1 + 1.5
>>
>>
>>> * [Status Bar] add information about selected item - kind of
>>> item,frame name,
>>> filename for image frames, dimensions
>>
>> we should have a good solution for showing information and avoid
>> cluttering the status bar... imo...
>>
>>> * [Search/Replace] search and replace in whole document
>>
>> 1.4 / 1.4.1 + 1.5 (depending on how invasive it is)
>>
>>
>>> * [Style Manager] set default style for replacing during deleting
>>> styles to
>>> "Deafult Paragraph Style" instead No Style
>>
>> 1.4
>>
>>> * [Properties Palette] tabs switching automaticaly related to
>>> selected item
>>
>> 1.4.1? (will not be needed anymore in 1.5, since there won't probably
>> be tabs anymore)
>>
>>> * [Properties Palette] applying Paragraph Style dont clear local
>>> character
>>> formatting (need some fix for proper behaviour while opening old SLA
>>> files)
>>
>>
>> 1.4.1, if it's possible to make it work with old SLAs
>>
>>
>>     *
>> *     *
>>
>> but all depends on how long 1.4 will be around...
>>
>> if we don't want any new feature in 1.4.x and 1.6 is planned for some
>> time next year (i hope it's planned for next year!) all the changes
>> marked as 1.4.1 can be directly applied to 1.5 only.
>>
>>
>> ... just my 2mio francs...
>
> Putting versions against these is a bit early. We need to see bugs with
> diffs for each change. Once we see the diff, we can see the complexity
> of the change, and therefore judge the impact. Low impact might mean ok
> for 1.4.1.
>
> And yes, 1.6 should be released next year, at a guess. No reason why not.

In the bigger picture, is there any possibility that sometime in the 
future, we might see a 'hard' release cycle, e.g. every 6 months, 9 
months..., in which we say, 'Even if we might have to delete incomplete 
new features, we will release a new, workable version in this timeframe'?

I think what this adds to a project is a credibility, and perhaps 
soothes the teeming masses. To delay a new release a week or two is I 
think tolerable, but when delays seem to have no boundary the natives 
become restless.

Greg