How do you handle deployment and notifying users
It feels weird to have multiple versions deployed on a single day. Like today, I would've had v1.0.4 with two things, one new feature improvement and one fix. Then on 1.0.5 a single fix. This feels strange, especially when it comes to release notes having a single thing listed. From work I'm used to spend a week or two doing new features, improvements or fixing bugs.
But at the same time it also feels more correct to deploy these things as soon as they're done.
So I'm curious about how you do these things
I would just do a weekly recap. Call it something like Release Wednesday, or something that has a ring to it so your customers remember it!
That's a good idea! If you can stick to that schedule, it also means customers can eventually anticipate and plan for disruptions.
That's a neat idea! I'll do this for sure :)
Deploy as I go. I don't let users know / there's no need for release notes.
If there's planned downtime due to something that actually needs downtime (long database migrations), I'll put up a warning a few days in advance and put the app in maintenance mode.
I want my users to be able to see what's going on. I like transparency. Got a good suggestion in another community where I deploy as soon as X is ready. I then accumulate a list of changes to a private change log, then make that public once a week.
May I ask why you don't think there's a need for release notes and not letting your users know about new features, improvements, fixes?
I'm all for transparency, but on my projects (and at work) we deploy upwards of 10+ times/day. That's way too much noise for end users. A lot of it they won't care about too.
If there's a specific user who told me about a bug, I'll let them know it's fixed.
Or if it's a large feature, I may shoot out an email or a blog post about it.
Otherwise, it's all about small incremental changes that generally don't warrant a public-facing changelog.
Fair enough :) I've decided I'll try out the MAJOR.MINOR.PATH.BUILD versioning, and have a set day of the week/every two week, where I will bump the PATH. The progress up to that bump is what will be added as the release note... This might change, but it feels correct at this point :-)
If you're a single developer on the project, it can get tricky. More often than not, I plan on spending a week or two doing a bunch of minor non-breaking fixes, but then something urgent comes up, and it's easier to just release whatever I have at that point. Trying to juggle one git branch per feature, then merging the urgent fixes without impacting the low-priority ones can just get extraordinarily messy (I'm a big fan of the "master is always deployable" rule)
I generally only notify customers when the changes impact some part of their workflow (new buttons etc), and just lump up any internal efficiency updates as "performance and security improvements". Customers are always expecting those updates though, since they're the ones that asked for them :)
Yeah I'm the only developer, and I use the same rule. I have one branch always stable.
I don't post any updates as I don't need them for my product, but I would go with manually prepared monthly posts with highlights. Well written text + some screenshots feel much better to me compared to a simple change log.
That's also a cool idea that I probably will adopt. Keep the release notes for the interested, then push a monthly newsletter about the highlights. This could also link to the release notes at the bottom if they want more details
I'm not sure. Never had a SaaS that had enough users to notify of new changes/features.
My gut is: Release when it's ready, but don't notify based on individual releases - choose when it's important, or delay a notification if you're likely to do another release very shortly after.
I don't have a lot of users currently either. But I have learned from talking to the few I've got that they want to know about progress, to know that it's not being abandoned :-)
I release as soon as the PR is merged into the master branch. I announce new features every couple months (to give myself time to at least introduce a few features every announcement and to avoid feature spam), or sooner if there's something noteworthy that I know customers will like to know about. I do my announcements through Intercom. Customers don't know about bug fixes unless they were impacted.
I'm fairly early in the process of the project, so I want to show that this is something that is actively being worked on. Based on this I've decided on a new release once a week or no more than every two weeks if I'm working on a new feature which requires some additional time.
Yeah the feature spam is what I want to avoid which is why I'm looking at "the best" way to do this :)
If you're in the early process, then you should try to keep an open communication channel with a chunk of your more active users and announce features more often to them, since (hopefully!) they're the ones asking for them.
(If they aren't asking for them, stop building features and start talking to your market with what you have.)
Yeah I am actively talking to them, talking to one right now actually. And others are close friends which I talk to in person every day. We look at the product together and I observe how they use it, where it looks like they're confused or misunderstanding behavior :)
I use blue-green. Two prod code running. One connected to the public and one not. Using router at firewall. No need for Dev server.
Well, personally, from how I understand your comment, I would call your non-public prod code dev. Because it's not always identical to what the public sees and it's where you create new things, fix bugs, etc before moving it over to the public.
I don't have a dev server. I have a subdomain and a branch for devevelopment code which is merged to production as soon as it's done
This comment was deleted 4 years ago
Yeah, I will deploy as I go, and then do a release note for the past week. This will then be linked in a monthly newsletter