Next beta

[xnview]

For next beta i'll think to change the current step.
Building QT + XnViewMP on linux (ubuntu 6 + ubuntu + MacOSX (10.4 + 10.5) + tests is a long process.

So perhaps it will better to release more often a windows version, and every 2 months all versions..

What do you think?

[PSHRutPark]

For next beta i'll think to change the current step.
Building QT + XnViewMP on linux (ubuntu 6 + ubuntu + MacOSX (10.4 + 10.5) + tests is a long process.

So perhaps it will better to release more often a windows version, and every 2 months all versions..

What do you think?

My interest in Xnview MP is centred upon it being able to run on Ubuntu as well as Windows. I guess I can be patient!

Peter

[budz45]

For next beta i'll think to change the current step.
Building QT + XnViewMP on linux (ubuntu 6 + ubuntu + MacOSX (10.4 + 10.5) + tests is a long process.

So perhaps it will better to release more often a windows version, and every 2 months all versions..

What do you think?

Yes I agree.

Tough but fair.... Other OS users are not the majority as much as Windows users

[oops66]

Hello,
Yes, If Pierre is "over booked" Yes, but I am not sure that is a good idea (especially during the MP development) because there is a lot of feedbacks from Linux users too (even if it's a minority) and these feedbacks should also help to better developing the MP Win version (the requests are mostly complementary and almost never redundant).
Basically and during a development phase when the project is too mature on a particular way, it's very difficult to go back (without spending to much time) to implement some others functions, GUI interfaces or different behaviors, so I not sure this is a good idea ?

[JohnFredC]

It's a matter of distinguishing bug-fix priorities from enhancement priorities, but within the contexts of the deployment environments XnView supports.

That suggests the following development life cycle:

• 1. "Major" enhancement and bug-fix release (all environments)
  2. "Minor" bug-fix sub-releases
  • 2a. General fixes & minor enhancements (core code + GUI), all environments
    2b. Windows-specific fixes (bugs only, no enhancements)
    2c. Linux-specific fixes (bugs only, no enhancements)
    2d. Mac-specific fixes (bugs only, no enhancements)
  3. Go to #1

#1 may be feasible in the MP case because one of its purposes (as I understand them) is to have all features available in all deployment environments. If so, for enhancements, the core code-base is essentially identical? Yes?

...and environment bug fixes are at the periphery, where MP interacts with the file systems and what not.

A nomenclature which adds a decimal or letter to the major release level would help distinguish the releases in #2 (above). (0.25.1.w or 0.25.1.l, for instance):

• 0.25 major release
  0.25.1 minor release, bug fixes and minor enhancements applicable to all environments
  0.25.1.w minor release, Windows bug-fix specific

All releases would be available for download and installation for all environments, but a Windows user (for instance) could skip the Linux specific releases without fear of missing an important enhancement.

All enhancements and fixes would be cumulative, that is, present in each release, regardless of environment (if that is possible).

The forum announcement for a release could say something like:

• XnView MP v0.25.1.w has been released. XnView MP v0.25.1.w fixes bugs specific to the Windows environment. Linux and Mac users may safely skip this release as it does not address those environments and does not enhance v0.25.1.

Perhaps this specific schema is too complicated in practice, but the general idea might work.

I would also recommend a separate locked sub-forum for beta release announcements instead of the stickies at the top.