I’m reading about different batches and different formulations of version 2.0 here in the forum.
If it’s a different formulation, I would expect there to be a version bump. Perhaps a point release, and if there’s a new batch, then perhaps a double point release.
Having batch numbers when you already have versions seems a bit odd to me.
The batch numbers are the same recipe therefore the same version number.
I’d read in other threads that the batches were using a modified recipe. That may not have been information from Huel itself though.
Not true. Ingredients can change within a version number and seems to have done so on a number of occasions.
I think batch numbers are important from a manufacturing point of view, but I agree that the version number should be incremented for every change of ingredients (somehow whether 2.0b 2.0.1 or whatever)
Usually when they use a different batch of different ingredients the batch number changes but the quantities and ingredients usually stay the same (same basic formula)
Yeah, it would be a good idea to have standardised versioning scheme and publish a list of ingredients for each version. It could be done very easily using one file stored on github and tagged with the version number.
Usually, but there have been a number of exceptions noted where they have changed the formula without incrementing the version number. For example changing the gum, I think there was another example too.
Semver seems to be the “cool” numbering system to use these days:
(I have no opinion on this and am happy with anything, so long as it’s consistent and logical)
Thumbs up :). The first scheme I thought about but was not sure about how it would translate to this problem domain as I could not think about any category of changes to the recipe which would not break “compatibility” 
This happened again 
The sodium content was dropped, but the version number not changed. It basically means the version number is irrelevant.
This really is a missed opportunity for the product. At this stage they might as well just drop the “version number” entirely. It’s just for arbitrarily drumming up interest and keeping up with the competition.
More label changes mean more wastage though. Every time I make a label change it means that these is chance some get thrown away, which I really hate having to do. If we update the batch number and tell you what changes we have made, as we did with salt, what difference does it make if the number in the top right has changed? We change the version number for multiple changes, not just when we make 1 change. I hope this makes sense.
Just leave 2.0 as the main label, for branding purposes. But replace your batch numbers with version numbers so that we can see what version we are actually at. Just replace the batch numbers already printed on the product with the complete version number.
You have copied the versioning system used by the software industry, which makes sense, but you have failed to implement it properly. Microsoft sells Windows 10 in shops, but the actual version number is currently (something like) 10.0.2.24. The actual version number is there, but they don’t outwardly market it as such, but it is there for those who want to look it up. What you guys are doing, is like Microsoft having Windows version 10.0. But then secretly behind the scenes changing stuff without ever bumping the version number.
Huel is a product where we have to put a lot of trust in you to:
Adding a more granular version number next to the batch number would be great for #2. Bonus points for maintaining a simple changelog on your blog as well. I’m not going to re-read the entire label every time I order but if I see a version shift and can look up what the differences are I’ll be informed and confident in what I’m getting.
I agree with everything @ryanhellyer says with the version except for replacing batch with version. You need both I think
So the product would be marketed as v2.0 but would have true version of say 2.0.xxxx. You then need the batch of say yyyy. The reason for this is trackability (you may not need it yet)
Let’s say in the future you are making way more Huel than you do now, you order new batches every week as you get through it so quickly. For the last 3 months you haven’t changed the recipe so the version says the same. Suddenly you find an issue with a few batches of Huel which needs to be recalled. You need to know what batches were effected otherwise you have to recall all the Huel with a certain version. If you had kept the same version for 3 months but the issue only really effected the last week of Huel made, without a separate batch you cannot recall just 1 weeks worth.
We already have batch numbers and can recall those currently.
@aprice30 The unique batch number would remain for manufacturing traceability. What is being suggested is to use the date coder at the factory to print the expiry date, version number and batch number. This way the version number can be changed easily without having to reorder labels. The label on the packaging would just be V2 or something similar with the full version printed on the packaging. I think it’s a good idea.
Wouldn’t it be easiest to just stick it all in the version number?
So batch 234 of version 2.0 recipe #4 would be 2.0.4.234
The way it could work is this:
v2.0 is on the label.
The batch is printed by a different machine onto the pouch. e.g. 2469.
So by adding the two together (although they won’t be written together), we can be more precise. We can then give specific details on the site for v2.0 (2469) on the website for minor changes. E.g.say the amount of surcalose has been has been changed, the amount of sucralose is not defined on the label so it’s pointless reprinting just to say v2.0.1
For anything that includes a change to the label but isn’t major say carageenan is removed, we would create a new version number e.g. v2.0.1, then for major / multiple changes we would moved to a new version number e.g. v2.1