Determine whether we need to make installers for all minor releases
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.
#3 Updated by David Welker almost 10 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.
#5 Updated by Matt Jones almost 10 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.
#7 Updated by Christopher Brooks almost 10 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.