Did I get this right that FM 19 will not support High Sierra? Release date 9/20/2017.
But it will support Windows 8? Release date 8/1/2012.
Yes. The support isn't based on release date. It is based on a combination of what most clients are using and 2 versions. It's just that Windows hasn't done a major rev of the OS in 5 years. So the last 2 versions are 10 and 8.
1 Like
I don't know where you get your info - as far as I understood is that Apple pushes their developer user base to upgrade to evoke hardware sales which makes sense but is not so nice to to enforced for their user base ..IMHO
1 Like
My expression isn't opinion. It comes directly from talking with Claris engineers, management, listening to explanations given in the past on the community by people like Rick Kalman.
Holding on to older operating systems has a serious impact on what the engineers can do. This is especially true because of how Apple does try to push their users to newer hardware. However, that's not a statement about hardware. My 2015 Macbook Pro has gone through 6 operating systems, and it's still running great. In my house I have several older Mac Minis ( 2012-2016 ), and a 2008 Mac Pro. It was only the last 2 OS versions I was not able to upgrade the Mac Pro. So it hardly seems fair to say that is their move. My mac hardware lasts longer than my windows hardware ( 2 windows laptops, and a desktop ), by a lot.
2 Likes
Well thanks for the input. I agree with both of you. But now I have at least a rudimentary understanding of why I need to upgrade my Apple hardware to keep up. That helps me swallow the pill. My old late 2009,27", i7, SSD upgrade stills runs great as all of my Macs have. But I hate to give her up and abandon her to the grand kids. But she will have a good life at that.
2 Likes
interesting - i asked also one of the engineers at a Partner meeting why their version cycle is annually and so fast that until a stable version is reached (and sometimes not even then) the next version comes out without being in sync with OS versions. His answer was that Apple requires them to update once annually so it is not their choice...
My questions were: Why don't you fix the bugs first before introducing a new version with potential new bugs? And what do I tell my clients who are buying new Mac Hardware but everyone tells me not to jump right on to the newest FM version until at least v3?
2 Likes
I can't speak to what he told you. But all of that is moot at this point. The entire development cycle is changing. It will no longer be an annual release.
I do know that some of the direction regarding security pushes comes from the mothership. But all expected, and not everything.
2 Likes
shorter then annual? (that's what has been stated at official roadmap online presentation ..)
How would this improve the QA situation?
Yes. The releases will be much faster. And essentially no more "version" releases, like FileMaker 19. Going forward it will just be FileMaker Pro, and then the build will just be to identify version you are using. As a feature is ready, it gets included in the next update. More in line with a quarterly release.
The greatest benefit, they don't have to rush a feature out the door, nor do they have to wait a year. They get it ready, if it's not ready in the May release, its ok. The next update is probably only a couple months away. That should go a long way to both code quality, and feature set. Also, it should be easier to push bug fixes into a release.
we had bug fixes in the past via the v-revisions (as in FMS18v4)
why is this easier then before?
thanks!
2 Likes
The decision making process will be different. The development cycle is different. The direction the engineers are given will match the new vision of the product.
A shift in the development cycle will have many intended, and unintended, consequences. Historically, the patches FileMaker provided were extremely limited. Now that they don't have the limits of annual "Feature" releases, some features can include fixing things that Claris doesn't view as a bug, but we do. So a behavior change ( of which there are some in 19 ), a feature that is closely tied to another process in the engine that require a bug fix won't get put off until next year.
FMI doesn't fix the bugs that are known as it is now. I don't see how a shorter cycle fixes anything...
One example ... There's a glaring design flaw in the way FMI stores debugger watch expressions in the plist that was still not fixed in version 16.
1 Like
Sure there are a lot of bugs, we get it. We've had this discussion before.
As for the not seeing how the shorter cycle helps, I didn't say fixes, well, that would require you to be closer to the people in the company than you are. I've talked to the people. I have seen their vision, and passion for what's coming.
Not the FMI-internal developers I'm worried about. I won't get into my list here for features (posted elsewhere on this forum) that I consider essential (but still missing in FMP) for any serious development product.
Thanks J.
I think we should not see it as "shorter cycles" but instead as "more frequent cycles". I don't think they will try to rush to make one specific deadline, so we should get things when they are ready not before as it may have been in the past (not making a release meant the feature would have to wait a full year).
I have some apprehensions and some doubts, but it is a change I welcome.
3 Likes
The metric I use is code quality. How you get there (more/less frequent releases) is not that important.
I think FMI could benefit from all developers (and managers especially) reading books like Code Complete, Debugging the Development Process, and others.
I won't jump on the forced subscription bandwagon and have dumped many products in the past when that was the only option (Adobe, and others).
1 Like
Multiple, overlapping cycles that are not given a forced deadline. It changes your developers, natural occurrence.
Small point of order, but FMI doesn't exist any longer. lol
I agree from an indie perspective, the release cycle isn't that important, but from a company product perspective, companies live and die by their ability to have the correct cycle for the product. This new dev cycle caters more to their ability to increased code quality, and an ability to pivot faster than they could be before. That's a pretty significant difference.
I know for us, we moved from mostly live development to a stricter dev-migrate-production flow. It has made the development easier, with better code quality, and a less reactive environment.
1 Like
Sounds all nice and cozy but how does this lead to better QA? How??
1 Like
It will always be “FMI” to me. LOL.