Hey, just signed up in the hope that this becomes the next big thing!
what is your planned release cycle?
ta
Last year I was able to push out new releases every couple months or so.
Version 1.0.0 has been baking for a while now, and the current alpha seems like it doesn’t have any show-stoppers, so the next build may graduate to beta, and after a couple days, I’ll finally release v1.0.0 stable.
Version 1.0.0 is a beast of an update:
- almost every single moving piece that PhotoStructure relies on has been upgraded or changed, and required internal code changes to accomodate (like electron, the docker base image, HEIC rendering, custom UID/GID docker support, RAW decoding, …)
- privacy-friendly, transparent and portable licensing that doesn’t “phone home” except once when trials end or subscriptions renew (and even that can be disabled, in the interests of privacy)
- search required a new FTS index and query grammar/parser
Once v1.0.0 is released, I expect a much more frequent cadence of releases (more like last year, and hopefully more often).
1 Like
Awesome - i love new releases 
on the assumption they dont break anything!
At it’s current level of maturity, the speed of new features is going to be very exciting 
I’ve debated even posting this because of course I’m taking away from your development. But after 14 months and no “is-it-done-yet” posts, I hope you aren’t offended 
I’m hoping to see another stable release soon, it’s been awhile! 14 months to be precise since 1.1.0. Might I suggest a goal for a stable release every 6 months with at least one of the top-10 features in Feature Requests - PhotoStructure Forum? Then PLUS subscribers can experience more regular progress without needing to resort to alpha/beta builds. Also I have at least one friend who has said many months ago that they plan to subscribe, but are waiting for the 2.1 release before they actually sign up due to the many significant changes, so you’re losing out on some subscribers due to less-frequent updates.
Personally I’m really looking forward to Archive/Remove/Delete Photos which has been available in beta/alpha for months but not in a stable release yet. Clearly you’ve been working super-hard based on your excellent detailed release notes, but at some point I think you’ve got to start ignoring bugfixes and refactoring to focus on show-stoppers and regressions and just get another stable release. I don’t want a rush job, doing it right is certainly important, but I’d prefer more frequent updates with less improvements in each.
i’m a bit disappointed in PS, as i had subscribed, but ultimately gave it away. For me, it was the point where i could not click through images in order, and they jumped all over the place. A photo gallery should allow you to view the photos!
I hope it succeeds, there is a vacuum of decent, affordable solutions, and i really hope you nail it!
1 Like
I second the conserns above, I’ve opted out of plus for now. I don’t doubt there is significant work beeing done but with the slow phase of releases you get a feeling that nothing is happening.
I my opinion, alpha should be cutting edge testing prerelease code, released weekly or bi-weekly, Beta montly or quarterly and stable ~6months.
Much smaller increments but I think it would generelate a lot of more feedback and community activity.
With that said, I am very hopeful because Photostructure have great potential and fills a void in this category of software.
As @palitu mentioned context aware browsing is a dealbreaker. The number of times I’ve gotten lost trying to fiddle my way back to the view that I was in is uncountable. I can understand whats happening and why but when my wife tries to use photostructure this makes absolutly no sense and apears random to her and she consider it broken/unusable.
Additionally, small things such as opening up photostructure on the phone and showing someone a folder of photos and not beeing able to swipe left/right. There are a lot of small usability/presenting features that I think should be prioritized for the project not to lose momentum.
I hope this didn’t come out as harsh but instead genuine feedback as I truly have great hopes for Photostructure.
//Hannes
1 Like
Is there a particular reason you haven’t installed alpha yet? There’s a reasonable argument that 1.1 stable is no more stable than the current alpha. The instinct to stay on a “stable” release channel is understandable, but with immature software like Photostructure, the “stable” release is really just a milestone marker. @mrm isn’t ready to declare that he’s past the next milestone, so we’re still in alpha/beta phase.
Of course, you should be taking care that you’ve got good, reliable backups. I’d argue that you should have that even if you’re running “stable”.
Let’s all remember that Photostructure is a young product being developed by a single developer, one who is incredibly transparent in his progress. The pace we are moving is the pace that @mrm can handle. He’s shown himself to be thorough, and he’s built a great piece of software that is filling a need that many of us have. I encourage you to stick with it, because I’m certain that Photostructure is going to grow into a fantastic solution.
Yes, I understand it’s being developed by just @mrm and as I said, I want him to do it right. And I greatly appreciate his thoroughness and transparency. I’m still subscribed. But now we know of at least three people who aren’t currently subscribed due to lack of stable updates.
I would encourage @mrm for future development to think about ways to do more stable releases even when it causes some code duplication and is slightly less efficient. For example could he have gotten a 2.0 stable release with an extra month of effort while he was already starting 2.1 development? I don’t know. But if yes, then I think it would have been worth it. Besides encouraging more subscribers, I suspect more stable releases also encourage more forum interaction and help focus his development efforts. Timelines are extremely difficult to estimate, and I doubt @mrm ever expected another stable release to take this long, either, but the fact remains that it has.
Concerning why I don’t install alpha
I haven’t installed alpha because @mrm strongly discourages me from doing so in Alpha, beta, stable, and latest; What should you use?. Also as he says, “It’s no fun to run buggy software!” Also it’s not just me you need to convince, it sounds like you’re encouraging everyone to run alpha so they have the latest and greatest features.
If the current alpha is truly just as stable as the 1.1 release, then @mrm should mark it as stable or even just beta. But he isn’t, which means he still expects substantial changes which may for example force full library rebuilds, make the library inaccessible, or even require actually restoring from backup. Stuff that’s “no fun”.
My backup is on a hard drive at a friend’s place, so updating the backup and restoring from backup are pretty inconvenient, but it works for me since I rarely change my files. It’d be cool to set up two Synology NAS’s at different locations to automatically sync, but the risk/benefit isn’t worth it to me at this time when my files rarely change anyway.
Thanks for the feedback, y’all!
I completely appreciate the frustration with a lack of a stable release. It frustrates me as well.
The v1 codebase was tested and released using SSDs and max-8 CPU cores. It became apparent almost immediately after the v1 stable release that people with quite large libraries, powerful CPUs (12+ cores), slow disks (HDDs), or, worse, several of these attributes, would cause thrashing in the SQLite write-ahead log that would result in stalled and failed sync runs.
V1 concurrency assumed every file being synchronized concurrently could keep an open connection to the SQLite database. I rebuilt concurrency in v2 to use a new threading model that kept all SQLite I/O on only three processes (main, sync, and web), and CPU-heavy work (like image hashing, metadata inference, transcoding, and image preview generation) on separate processes. v2.0 went through the alpha and beta build process, but due to several reports of database corruption, I felt like I couldn’t ship v2.0 without tracking down and fixing that issue.
v2.1 reduced concurrency further by removing the main writer, replacing the RPC event moderation with fsevents, added external write-level concurrency locks to the sync process to avoid these corruption issues, and adding several different strategies to the startup process to try to “heal” sqlite_corrupt situations. However, the integration test suite (at this point over 10,000 tests) don’t pass on all platforms, and I’ve been working through each failure in turn to get the continuous integration suite back to being green on all OSes, which has proven to be quite time consuming.
Once the CI suite is back to all green, I’m wanting to do much more regular releases.
3 Likes
Thank you for the explanation! It’s a long wait this time not because of feature creep, but because of initially-unknown show-stopper bugs in 1.0 that are still getting worked through. In some sense PhotoStructure has no stable releases yet and we’re still in the initial development stage.
And once PhotoStructure has a truly stable release, you’ll be able to dedicate much more time to shiny new frontend features 
At a minimum, alphas should be released much more often. 2+ month between the last 2 is no good. I’d rather have more frequent alphas with a few fixes in each, than infrequent alphas with release notes that are a page long.
Photostructure 1.1.0 already provides a ton of value for me. And I’m excited for all the things coming down the line. Just want to say thanks!
1 Like