Bug #5126
closedDetermine whether we need to make installers for all minor releases
0%
Description
It seemed like a foregone conclusion that installers would be made for all minor and major releases. On the other hand, minor releases are the smallest level of release that allows the addition of new features (patches are supposed to be bug fixes only), and the generation of installers is still not fully automated. Perhaps a different policy on when installers are made should be considered.
Updated by Derik Barseghian over 14 years ago
Today we decided not all minor releases require an installer be released. 2.1 will not have an installer, users will get it via the Module Manager.
Updated by Christopher Brooks over 14 years ago
So, once Kepler-2.1 is released, if I download the 2.0 installer, will
I automatically be updated to 2.1? How will I know that I'm running 2.1?
If I'm not automatically updated to 2.1, then will the user need to
update manually?
Updated by David Welker over 14 years ago
If you have 2.0, you will be able to get 2.1 using the module manager. It will not be automatic. In general, if a minor release does not have an installer associated with it, a user will need to get it using the module manager using any installed version of Kepler.
Updated by Christopher Brooks over 14 years ago
If we don't automatically offer updates, then by default, users will
be using 2.0.
This seems wrong. Why bother with 2.1 if new users will not automatically
use 2.1?
Maybe I'm missing something here?
Let's leave this open, pending discussion.
Updated by Matt Jones over 14 years ago
I think we're all in agreement about wanting installers most of the time. However, in the case of 2.1, the changes are minimal and focused on just delivering the needed changes to support the new reposting modules. So, if someone chooses to install the reporting module (via the module manager), they will automatically also get the 2.1 upgrades needed to support reporting. The next major release would be 2.2, and we would plan on building an installer for that. Our hope was that by 2.2 we could fully automate the process of building the installers so that this would no longer be an issue (because building the installer would be simple).
One thing we might consider is to have the module manager check for updates to their installed modules and prompt users to tell them that upgrades are available. This would help to allow quick updates for users that already have Kepler 2.0 installed so they don't have to get the whole installer when just a couple of modules have changed.
Updated by David Welker over 14 years ago
Does anyone object to me closing this?
Updated by Christopher Brooks over 14 years ago
Thanks, I'm closing this one.
We run the risk of users not having the most recent version and
of confusing the user as to what version they are running, but
since 2.1 is really only necessary for the reporting module, and
2.2 should be out shortly, then we should be ok.
I see these usage scenarios:
1) User downloads 2.0 and uses it.
2) User downloads 2.0, gets the reporting module and gets 2.1.
A better usage scenario would be:
1) User downloads 2.0, we automatically check to see if there is an update.
If there is, we suggest that the user install 2.1.
2) User downloads 2.0, if they have want the reporting module,
then they are forced to upgrade to 2.1.
The advantage is that it means that most users will be using
the most recent version.
However, we can live with what we have today for the short term.
We should watch out for the 2.0 vs. 2.1 split in support email though.