So I want to put this one out there to get a little feedback from the community.
The next version of Foundry is going to be v4. This is a ways off still, but I have started on a good deal of code. This new version of Foundry will need to take the place of the current version that customers have installed. This ensures that you don’t need to rebuild your pages, just install the new version and you get a lot of new features, new tools and it just works with your current projects.
Unfortunately when I released Foundry v3 I named the current file
Foundry3.stack. This was in an effort to not overwrite
Foundry.stack, which was Foundry v2. This was because we needed both Foundry v2 and Foundry v3 to both be available within the Stacks Library. With this next version though, like I said, we want to have it overwrite the current version so that you don’t need to redo your project files.
I can keep the filename
Foundry3.stack even though what will be contained within is Foundry v4, but I think this could be confusing to customers when you buy and go to install your newly purchase Foundry v4 upgrade.
I can name it something else, say
Elixir_Foundry.stack as an example, but then I need to teach people how to manually remove the old
Foundry3.stack from their Stacks library folder within the RapidWeaver addons so that they don’t end up with conflicting versions installed, which I feel many people may not be comfortable doing.
I’m not sure there’s a good solution, but I wanted to present this to the community to get feedback. Do you feel either of these is better than the other? Do you have thoughts on a different approach?
Can you update the stack and make the icons a different colour and/or look in RW?
Distinguishing the two in the library is unfortunately not the problem. The files for the new version have to replace those of the old version. Whether done by RapidWeaver installing the file or the file being manually installed. This isn’t a case where bot can continue to exist together as with v2 and v3.
I’d suggest Option 1: "Keep Foundry3.stack name
Both options have downsides, but I think Option 2 will be much more problemmatic than Option 1. Yes, there will be folks you need to help/remiind/nudge with Option 1 as well, but I think the support amount and time will be more than 0 but still much less than using option 2.
I can’t think of a perfect solution … maybe something will come to you while in the shower! But personally I don’t see Option 1 as a problem at all.
Yes. That’s what I meant. If you have to have the same version number then the actual icons in the library could be different. Maybe with a different colour or look?
I think we’re talking about two different issues unfortunately. The one that is the problem is getting RW to replace the
Foundry3.stack in the addons folder. Distributing something labeled
Foundry3.stack is confusing to people when the actual version contained within is Foundry v4 or v5 or whatever.
The problem I see is –
- User buys Foundry 4 upgrade.
- User downloads Foundry 4 upgrade.
- User opens Foundry 4 upgrade.
- User finds a file called Foundry3.stack inside.
- User emails me for support.
If I name it anything but
Foundry3.stack RapidWeaver cannot overwrite the existing Foundry 3 version, as I need it to do.
Hi Adam, seems you are a bit trapped as all of your ideas will have the one or other downside.
A manual removing of the old file I would not do. According to the knowledge of the user you will probably get into problems and create a lot of support tickets.
As @mitchellm wrote I would more prefer that the filename stays the same.
Another idea could be that you are staying also with the next major release with the name Foundry 3, as it is based on this “technology” and give it an additional name like Mark I, Mark II, Mark III or Catalina, Big Sur, Monteray or 2023, 2024, 2025…
But with such a system you will loose some marketing momentum as it maybe feels to some people as a minor release.
This is similar to an approach @Fuellemann suggested to me. His suggestion was to make this a v3.5 update. But I think classing it as a named upgrade, much like Apple did with OS X, may be the right approach. And as you say the base of Foundry 3 is the same, just adding lots of new features and lots of new tools, too.
That to me sounds like the best answer too, I still refer to Mac OS as OSX whether it is Big Sur, Sonoma etc, that makes me about 20 years out of date Although it would be a new major release it still gives the assurance to the user that is an evolved continuation of the familiar. Support tickets galore for file renaming and possibly question after question if renamed as new version along the lines “do I have to rebuild my site”, which would be a fair question, but could be reduced, similar to the question does the Thunder pack work in V3. Fair question, but happens a lot.
@elixirgraphics Not sure if this is an option, but what about including the year it is first released. For example ‘Foundry3.23.0.stack’ or a variation of this? Updates throughout the year could be ‘Foundry3.23.1.stack’. In 2024, it could be ‘Foundry3.24.0’ etc. Marketing it would refer to the ‘Foundry Stacks’.
If you take a look at the Control Center in Foundry 3 now, or the release notes page, this is how the version numbering is currently done. This is why I think a named version will be the way to go.
Think about to use an installer script with version v4 which could do the magic for you.
The script could simply put the new version 4 as ‚foundry.stack‘ into the directory and delete the old version (foundry3.stack) afterwards.
All subsequent updates wouldn‘t require the script anymore (assuming that you keep the file name ‚foundry.stack‘).
Unfortunately I have no way to know where Foundry is installed since users can choose their own custom folder location for their RapidWeaver addons.
I suggest option 2; you can get rid of ‘foundry3’ forever. Just be careful selecting the name–think about future releases.
I agree with @owlyhawk. I think to bite the bullet now and not have the same issue in the future. But, then again, I don’t know how many users will need additional help with the upgrade. If it’s going to be 100’s, then, No Way!
Perhaps another solution would be to create the script for default folders as @TomS2 said, with detailed instructions should the installation fail, and then you’re only left with the rest who really just love weaving and are not interested in the surroundings.
This topic was automatically closed 24 hours after the last reply. New replies are no longer allowed.