Question for the prerelease community

[chaley]

To those of you who get CC prereleases, a question:

Background: up to now I have tried to bunch new features together into larger releases made every 3 to 4 months. I did this for both my benefit (end user expectations) and to avoid overloading the prerelease community with new releases. I could change that and make prereleases when I "finish" development of a feature. That would mean that the prerelease cycle is substantially shorter, but from time to time I might make a release that isn't exactly optimal.

My question: which would you prefer?

If you choose frequent releases then you would see new features as I build them, which could be months before I release them to the general public. For example, I have built reordering the grouping drawer and the sort menu, select-from-list for group by custom columns, permit languages in the grouping drawer, support for the Samsung K4A app, make the top-level group name not scroll, and sync books changed since they were last sent. None of these will be released for months, but they could all be made available to the prerelease group.

The downside is frequent changes, some of which might not be as stable as others (although I would rather avoid that ). You might rather not be bothered every week or so.

Comments?

[cycojesus]

I wouldn't mind more frequent releases.

[kaufman]

I would also vote for more frequent releases. I am happy to start testing and playing with new features as soon as possible, even if that means an occasional crash and/or problem.

Is it possible to split the list into an alpha group and a beta group? People would want more frequent releases could be in the alpha group and everyone else could get just the ones close to the release.

[PatNY]

Hi Charles ...

Personally, I much prefer a slower track, where the releases are a little more stable than what might be issued in the alternative schedule proposed.

CC more than meets my needs as is, so anything else is just gravy. As such, I don't see much benefit to risking instability in the libraries on my devices.

To veer a little off topic, I was just wondering how much of the future enhancements/changes in CC will be dependent on having Calibre 2.0 or higher. I have avoided updating Calibre because I read 2.0 is incompatible with XP, and I am still on XP on multiple computers. I am happy with Calibre 1.40 and don't feel the need to update that, but if it prevents me from enjoying new CC features in the future, then I may rethink things.

--Pat

[a_daley]

I think having a separate small Alpha group for those who don't mind the odd crash and things not working (ok if you have more than one device) versus a beta group for those who require a bit more stability makes sense for overall faster development...

Personally I would prefer frequent releases...

[DoctorOhh]

I think more frequent releases to the beta group would benefit the rest of the community since it could mean a longer testing phase.

So I'm on board with the more frequent releases.

[eschwartz]

Keep in mind that announcements about the prerelease enable people to have a heads-up if you think it isn't stable. And no one is forced to update.

If you can setup an alpha testing group that would be ideal. If not, it still makes sense to offer things as soon as possible. The prereleases are meant for testing unstable stuff anyway, might as well actually do so and get more testing out of it.

Just give an instability rating on the announcement post.

[DoctorOhh]

Originally Posted by eschwartz

Just give an instability rating on the announcement post.

In case anyone thinks your serious. Signing on to test means that instability is always a possibility.

[kaufman]

Originally Posted by DoctorOhh

In case anyone thinks your serious. Signing on to test means that instability is always a possibility.

I think he meant on a scale of 1 to 10, not as a binary choice.

[DoctorOhh]

Originally Posted by kaufman

I think he meant on a scale of 1 to 10, not as a binary choice.

I'm not a programmer, but I would think Charles releases versions that he hopes are stable so exactly how would a 1-10 scale fit in?

[chaley]

Originally Posted by eschwartz

Keep in mind that announcements about the prerelease enable people to have a heads-up if you think it isn't stable. And no one is forced to update.

If you can setup an alpha testing group that would be ideal. If not, it still makes sense to offer things as soon as possible. The prereleases are meant for testing unstable stuff anyway, might as well actually do so and get more testing out of it.

Just give an instability rating on the announcement post.

Originally Posted by DoctorOhh

In case anyone thinks your serious. Signing on to test means that instability is always a possibility.

Originally Posted by kaufman

I think he meant on a scale of 1 to 10, not as a binary choice.

Originally Posted by DoctorOhh

I'm not a programmer, but I would think Charles releases versions that he hopes are stable so exactly how would a 1-10 scale fit in?

I would not make releases where I know of something that doesn't work or that I have never tested. Doing so would be a disservice to the community and would probably create more work than I could possibly save.

The "instability" would instead be in how something is implemented, which might change because of feedback. We have seen several instances of this during other release cycles, and I have sometimes wished that I could have had the feedback earlier.

[chaley]

Originally Posted by PatNY

Hi Charles ...

Personally, I much prefer a slower track, where the releases are a little more stable than what might be issued in the alternative schedule proposed.

CC more than meets my needs as is, so anything else is just gravy. As such, I don't see much benefit to risking instability in the libraries on my devices.

This is another argument for two communities, alpha and beta. Having both alpha and beta groups is supported by google so I could do that.

To veer a little off topic, I was just wondering how much of the future enhancements/changes in CC will be dependent on having Calibre 2.0 or higher. I have avoided updating Calibre because I read 2.0 is incompatible with XP, and I am still on XP on multiple computers. I am happy with Calibre 1.40 and don't feel the need to update that, but if it prevents me from enjoying new CC features in the future, then I may rethink things.

--Pat

There is already one CC feature that depends on calibre 2, the "Use wireless device driver template for content server paths" option. I have two more almost finished, auto-sync changed books (the book file itself) and temp-mark books that have had read information synced. Compatibility with USB connections may require calibre changes. None of the others on the wish list jump out at me as requiring calibre changes, but then I haven't thought a lot about them.

[a_daley]

With using an Alpha group you could be simply trialing major fixes and new features, while CC still has minor unresolved problems (normally documented on release) which can be dealt with in due course for a beta group release...

Having been part of many Alpha testing groups, be aware it takes considerable time and can cause many errors to your device - please, please, please if Chaley decides to implement this and you are part of an Alpha group back up your device every single day and every single time you make a change - even if it is to an unrelated piece of software. Things corrupt and conflict so easily....

Also please do a full system recover to see how it all works before everything turns into dodo land and suddenly find it's not backing up everything and you've lost important data....

[chaley]

Originally Posted by a_daley

With using an Alpha group you could be simply trialing major fixes and new features, while CC still has minor unresolved problems (normally documented on release) which can be dealt with in due course for a beta group release...

Having been part of many Alpha testing groups, be aware it takes considerable time and can cause many errors to your device - please, please, please if Chaley decides to implement this and you are part of an Alpha group back up your device every single day and every single time you make a change - even if it is to an unrelated piece of software. Things corrupt and conflict so easily....

Also please do a full system recover to see how it all works before everything turns into dodo land and suddenly find it's not backing up everything and you've lost important data....

My intention would be to make intermediate releases to the alpha group once I have new functions/change that are internally tested. These releases might happen once a week, faster if comments call for it, slower if I am feeling lazy or traveling.

The beta group would get releases a week or two before I intend to make a general release, which generally happen every three months or so. The hope is that the beta releases are very close to production, and because of that I will be much less willing either to add new functionality at that point or to change them for anything that isn't a bug. Of course, the definition of "bug" is mutable.

a_daley's comment about backups is a good one. There is no guarantee that one can revert to an older release without doing a total uninstall. Reasons: releases change both the database structure and the meaning of settings, and reverting won't revert those changes. In general, doing a CC settings backup before upgrading will suffice unless there is also a database upgrade, but I can't guarantee this. And it is worth noting that this has always been true for prereleases. Having an alpha group won't change that.

[DoctorOhh]

Originally Posted by chaley

My intention would be to make intermediate releases to the alpha group once I have new functions/change that are internally tested. These releases might happen once a week, faster if comments call for it, slower if I am feeling lazy or traveling.

If you create an alpha test group, count me in.