We're in the final stretch of development to the new PortableApps.com Platform and we've been having some internal discussions on changing the version of it. 2.0 has been very long in coming and the final version will be quite different from last year's betas. Realistically, we've been conservative with versioning in the past, opting for 1.5 (which probably should have been 2.0), a too-long 2.0 beta which should have just been 3.0 followed by a 4.0 with categories soon after. So, we've been thinking about changing it.
Some options (including some silly ones) are:
- ^2 (Squared) - Because it's the platform squared
- 3.0 (Just skip one) - Just bumping it up a notch for good measure
- 5.0 (Monty Python) - A Holy Hand Grenade-style counter of 1-2-5 (3, my lord) as a bit of a riff on the arbitrary nature of version numbers.
- 6 (Our anniversary) - 2011 is the 6th anniversary of PortableApps.com (even though we started in March 2004, we didn't register the domain until January 2005)
- 6.0 (Mozilla homage) - Release around the same time as Firefox 6 (Aug 16th) and match their version as an homage to our first portable app: Portable Firefox 0.7+ in March 2004
- 10 (Binary) - It's 2.0 written in binary. We could then do 11, 100, 101, etc or switch back to decimal for later releases (which is more likely).
- 10.0 (Multiplier) - Because it's 10x better than 1.0
- X (Apple) - Just call it PA.c Platform X Mac-Style and go from there
- 11.08 (Ubuntu style) - Ubuntu uses a two-digit year and two-digit month for their versioning which takes away any guess-work on what it'll be.
- 2011 (Microsoft Office) - Just start using the year. Though this will limit us a bit in terms of showing off major updates within the same year.
- Names (Silly) - We could always annoy all the geeks and just have named releases with no version numbers. But I think that would be cruel.
What do you think?
Visit the Community page
Join our forums
Subscribe to our email newsletter
Subscribe with RSS
Follow us on Facebook
Follow us on LinkedIn
Follow us on Twitter
Follow us on Mastodon
Follow us on BlueSky
It doesn't matter to the non-geeks as much as it matters to the geeks. I'm kind of in both camps. But you know I've been watching PortableApps for a few years now, and I know you like to promise more than you can deliver, which leads to disappointment. With that in mind, I think the best option is Names. Jumping to 5 is stupid. It was dumb when Winamp went from 3 to 5 and it was dumb when 7-Zip went from 4 to 9. Jumping for the sake of jumping doesn't fool anybody, except Chrome fans, I think. 3.0 makes sense if you have some real improvements. The app updater was a game changer. If you think of everything before 2.0 beta 5 as 1.x, that as 2, and the next as 3, it shows progression. The year also makes sense since we seem to get a platform update about once a year, but it kinda limits you to that. Ubuntu style will just remind people how long it's been since the last update (BTW, does 11.08 mean you're looking at an August release now?). Names doesn't make any sense, but it's cool. Like how you called the last one Leo, just give it the name of a Greek or Roman god or constellation or planet.
2.1 Professional Home Edition Lite Beta 6a
If I'm not mistaken, Ubuntu uses code names during development and only chooses release numbers when the release is finalized. A lot of development uses that approach (Microsoft, Intel, etc.).
Year and month is an objective way to number releases - avoids the appearance of arbitrarily jumping version numbers.
Ubuntu style is a great idea, but keep the codenames. 11.09 Codename Leo
It just sounds cool, it's easy to understand and it doesn't have any difference regarding major or minor releases, it's just A release. That way people aren't expecting any bells and whistles when they see a bump from 2.0 to 3.0 or anything
The reason Ubuntu can do the version numbering they do is because they always deliver in the month they promise. They work on fixed 6 month development cycles, and that means that "it'll be ready when it's ready" doesn't cut it with them. There is ALWAYS a new version every 6 months whether they're ready or not.
I think the fixed development cycle model has worked pretty well for them (and others) so I think it could be great for PortableApps too. It limits feature creep by design and necessity, and it leads to regular progress (which is good for morale on both the developer and user side). The problem with fixed cycles is when a feature is going to take a year to finish. Your version control system has to work well with multiple branches.
But if there's any doubt in your minds as to whether you can stick to your dates, the 11.08.x system will fall apart.
If you don't do Ubuntu-style, I vote for 3.0.
Oh, and no matter what, you should have cool codenames for each release
I think 2.0b5 was out for long enough and was widely enough used and accepted to put rest to the 2.x line after ironing out the last few bugs you have in PR1.
As for possible versioning formats (from least favourite to most):
Names: Just a personal thing, but I don't like them, and never have. Could be because I first started seeing them heavily on things relating to Apple, but I still don't like them when they are attached to Ubuntu releases.
Current year: As you say, it limits major updates throughout the year, and if there comes a stage when the platform requires minor maintenance updates and not much more, people will start to feel it is outdated because they are downloading a version from 3 years ago, or they will complain when 2016 has no noticeable features or changes compared to 2012.
Ubuntu style: you announce an 11.08 release - it has to be an 11.08 release date. You'll put more people off by talking about 11.08 and then having it turn into 11.11. What is worse is when people don't realize that it is year.month format, and start asking for 11.10 because there is something about 11.11 that they didn't like or broke for them.
5.0 - Jumping versions for no real reason seems anti-intuitive, and even when there is a reason, it kind of comes across as cheesy.
3.0 - This would be my choice. 3.0 would sit better with more people I think, as it sounds more like the logical successor to 2.x. Also, in most applications, there are major changes to both functionality and style in a new version, and while I wasn't around pre-1.5, the platform has had much more of an organic development in the time I have been around than some where they stop developing one version, start developing another.
I am against wild number jumping too.
Go with 3.0 for the final release.
"What about Love?" - "Overrated. Biochemically no different than eating large quantities of chocolate." - Al Pacino in The Devils Advocate
I think you should have a developer meeting and lay out a roadmap that takes you a couple of major versions forward.
Set your major versions to whole numbers, like 3.0, 4.0, and 5.0, then just stick to it.
While people are far more concerned with progress than with numbering systems, it's important that you keep a consistent system and don't make a big deal about it. If you constantly change the numbering strategy, it projects an image of disorganization that doesn't look good.
I made this half-pony, half-monkey monster to please you.
All the cool kids have released 2012 already. A release labelled "2011" could easily be seen as over a year old due to the way people have warped their numbers. AutoCAD 2012 came out four months ago...
I think 11.08 could work well. Definitely not names, though. How about starting at a certain Unicode character and going to the next glyph for each new release?
I am a Christian and a developer and moderator here.
“A soft answer turns away wrath, but a harsh word stirs up anger.” – Proverbs 15:1
Portable Apps Platform ¾ anyone?
¾ is too Harry Potter
"What about Love?" - "Overrated. Biochemically no different than eating large quantities of chocolate." - Al Pacino in The Devils Advocate
Portable Apps Platform 42, maybe?
Rick Carter
PortableApps.com Platform Dit-dah
PortableApps.com Platform Dah-dit-dit-dit
PortableApps.com Platform Dah-dit-dah-dit
PortableApps.com Platform Dah-dit-dit
...
8)
I agree with many of the points made by the previous commenters, but I've got a personal preference for the "date-scheme".
I've played around with computers since the C64 in 1982 and been in and out of various comp. sci. educations (from coding to UI design) ending up with a degree in the humanities and I think it's safe to say that the version scheme that makes sense to most people across various "fields" and educational levels (and with various understandings of computers) is the "date-scheme". That way you also "get the best from both worlds" meaning a logical and common-sense naming to the "regular" guy while maintaining the numerical progression important to (us) geeks.
Here's how I reckon it works best:
A yearly version called "PortableApps.com 20**"... with new features like the just released version with e.g. "Portable App Directory™" etc. This version should "arrive in stores" just before the new year (as in Holiday sales). I.e. the next version should be called "PortableApps.com 2012" and be released sometime in December just before Christmas and it should contain some kind of new feature(s). The rest of the year releases will only contain bug-fixes and minor improvements while all new functionality is added to next year's version. The release names will follow a traditional ISO 8601 (http://en.wikipedia.org/wiki/ISO_8601) naming scheme meaning an update (read: "update" and not "upgrade"... no added functionality) to e.g. the "PortableApps.com 2012" edition coming on the 16th of May 2012 will be called: "2012.05.16" ... possible even add a 24h timestamp like this: "2012.05.27 21:37:45"... This will obviously only be visible if you go to "About PortableApps.com Platform" while the "regular" user will simply see "PortableApps.com 2012" (possibly at the top of the menu) and will know they're using the latest version... being in 2012 and all.
Just my 2 bits...
Isnt it a bit limiting for the developers to have fixed date in the year where a new version is released?
"What about Love?" - "Overrated. Biochemically no different than eating large quantities of chocolate." - Al Pacino in The Devils Advocate
... on how you look at it really!? You could argue the exact opposite as well: Giving the developers more freedom to get the new ideas and functionality thoroughly tested and bug-free! A major reason for PA.c 2.0's delay has been "feature-creep"... adding more and more functionality instead of getting it out the door! If you have an exact date then there's really nothing to argue about! If a new feature ain't ready then it'll simply have to wait for next year's release! Please also notice that I did mention that "minor" changes is OK... e.g. moving the search box to the bottom of the menu between now and the next major release (X-mas) would be OK since it's already there (just placed "wrongly") but e.g. adding search when not having any in the first place might be considered a "major" change... it's really a matter of "taste". It would also give the users something to look forward to: A "X-mas present" if you like... that one time of the year where the PA.c team will show off their skills
What I think is much more characteristic for your comment however, is also what seem to have been (but hopefully won't be any longer) characteristic of the project so far: A focus on the developers first and foremost while "ignoring" the users! As much "fun" as the developers might have making PA.c as long as it's "out there" and is being promoted the way it is, it's ultimately for the users NOT the developers! So please get out of that "hobby-mentality" and try to be a bit more professional!... With all due respect
While you can choose a version based on a predicted release date, it's fairly common to not have a version number till you actually do a final build. Prior to that you have release candidates (Leo RC1), Betas (Leo B5) and test builds (build 5732).
One of the problems here (as I see it) is the rather long term and (frankly) aggressive promotion of 2.0B5, very much as if it were a release candidate (except you would never have a release candidate hang around for months and months without a final release). Typically you do not promote betas, and barely promote release candidates. No one outside the dev and test communities know (or care) that early builds don't have a version number, and the internal communities are in-the-know; they can handle it.
That's fine in theory, but I don't see the release dates being predictable enough to release a major version at any specific point in the year. Sorry, there isn't the development infrastructure to support that.
Here's where I see potential problems:
Since you likely won't see regular yearly major version releases, you will either get out of sync with the year (i.e, we'd be using PA.c 2012 in 2013) or you will have to release a major version in name only (i.e, at the end of 2012 release the same app re-branded as 2013).
I'd rather just stay with the 2.0, 3.0, 4.0 etc system. In fact, I believe that we should make the next release 2.0, period. That's what we've been promising for years; the last beta was 2.0B5, and the current one we just got is 2.0PR1, so the release should be 2.0.
Now I'm going to be picky: PR1.1? IMHO, that's putting too fine a point on it. Just fix bugs and release a PR2, and don't predict which at which PR you'll add certain functionality, just say a future PR.
These types of predictions have proven self-defeating in the past.
I made this half-pony, half-monkey monster to please you.
I hate seeing versions like that. It always takes me a sec to realize that there weren't 2011 releases when I see a new release. I don't like it.
I personally like it like in this example:
1.2.3.4
1=Big release, either the first time, or there's been a lot of changes, most importantly in the GUI
2=Medium release. Some larger, undiscovered bugs were found so that number had to be increased to show that the update is needed, but you won't see much.
3=Revision. Say in v1.2.3.4 you mispelled "OK" with like, "IK". I'd release 1.2.4.5 to show that the changes are not really needed, it's just there to be neat. Also works with small, unnoticeable bugs.
4=Build. I guess if you keep track of builds, it's nice to have this number (or 0 if you don't).
This makes the most sense to me. Chrome's versioning system (and now FF) is lame. I think they just do that to make it seem more "advanced."
Names are nice addon. Not needed but fun to refer to (like Android versions always have the name of something sweet after the version).
I don't quite understand what you mean. 11.04 means that the Natty Narwhal was released on April 2011, giving you full knowledge of what year and month Ubuntu was released.
Although Google did use this system to seem more advanced, it isn't the case for Mozilla. Mozilla used it to advance the web and its technologies quicker.
I used to think that Google Chrome's version system was just horrible. After Mozilla adopted it, I was upset at first, but then I began to read the blogs at Mozilla and figured out why. The Rapid Release Schedule allows applications to grow and deploy features faster, making it ideal version system for web browsers. Take this for example. Even though CSS Animations were close to being finished, it didn't make it in time for the feature freeze Firefox 4 Beta 7. This meant that CSS Animations would have to be kept back until Firefox 5.0 or 4.5 was ready, which most likely would not have been for another year. Dropping CSS Animations in 4.0.1 were obviously, not an option. However, since Firefox 5 came out 3 months ago thanks the new system, CSS Animations and everything else that was ready for deployment were given a change to be released many months earlier, allowing web developers immediate use of the feature much earlier than previously possible.
For this reason, I think the rapid release system is the best for the PortableApps.com Platform. Set releases will bring undelayed updates for the Platform. What's ready and does not contain bugs should be released. I bet many of the features in the new Pre-Release yesterday have been ready for a while, but had to be halted for the rest to finish.
One thing though. Although Chrome and Firefox have their Rapid Release Schedule set for every 6 weeks, the platform's should be around 4 months.
[Edit: Ubuntu has a system similar to the Rapid Release System, with set dates and a new version every 6 months.
I think you're objecting to four-digit year style versions, not Ubuntu style. Ubuntu style is 11.04. You might pause realizing there aren't 11 major releases, but not 2,011.
Personally I think revision and/or build info should be relegated to an about screen, not included in the version number.
Also, start at 10 (2 in base 2 :wink:).
Previously known as kAlug.
format Version number Dot Minor number Dot Year Dot Week Number
so the current version would be 2.0.11.29
I don't see a point in this. Why add an unnecessary date to the version number?
so given that you should not have more than one posted revision in a given week then
you can figure which version is which from the year and week number combo (and as a bonus be able to tell if your copy is older just from the date stamp)
Don't let the version number discourage you. It doesn't matter what version other software is on. All that matters is that Portable Apps is awesome! This is Portable Apps, not some other software. Keep it the way it was before.
-A3R05
Agree with these sentiments.
Maybe a bit of both eg 3.0 for final while each successive beta is done unbuntu style so a future beta might be P.A.com 3.1 12.03 for example instead of b5 and rubbish like that.
Just my opinion of course
Do what is least confusing for the masses, the geeks can deal with it (speaking as a geek).
Since we started the whole portable thing with Firefox 0.7+ way back when, and since this is a one-time-only change, we could call it 6.0 and release it the same day as Firefox 6.0 as an homage.
Sometimes, the impossible can become possible, if you're awesome!
That's a good joke
IMO
If you don't name it 2.* something it will appear that 2.* was a bad idea, had too many errors, needed to be rewritten so you created a 3.* or 6.* and discarded all the 2.* code. Not exactly a good impression for people to see.
Finish what you start was what I was brought up with.
Ed
I agree, stick with the 2.0 release for this incarnation of the platform, and go with 7.0 in conjunction with the FF 7.0 release if you want to do an homage.
Alternatively, you could always release one of the PR's as 2.0, with 6.0 being released in a few weeks in conjunction with the FF 6.0 release. That way everyone's kept happy.
[EDIT] Typo fix. I should've used preview.
The original path and plan of 2.0 was a bad idea and I made a lot of mistakes with it along the way, so the reversioning idea was to make a break from that. People have a negative connotation of 2.0 already. And the beta was out there for so long, that that's what people think of now as the 2.0 release.
Sometimes, the impossible can become possible, if you're awesome!
Based on that, I'm in favour of a clean break, going with 6.0, 3.0, whatever, doesn't really matter to me. I am in favour of numbered versioning, however, not named. Also, based on the lack of minor releases to date, and the proposed move to rapid release cycle, I'm in favour of an x.0 versioning system, rather than x.x.x.x
IMO wanting to make a clean break is not a good reason to change versions. It's too personal. I think it'll look best if you stick with 2.0 for now.
Think of it this way ...
If you change this version to 3.0 (or 5.0, or 6.0) you'll have a whole bunch of people who don't really care and a whole bunch of people who disapprove, some vehemently. I don't think you'll have many people that will actively approve.
If you stick with 2.0 you'll have a whole bunch of people who don't really care and a whole bunch of people who approve. I can't imagine anyone would disapprove - after all, 2.0 is what you've been promising all along.
You'll look a lot better if you follow through with 2.0. You can make a clean break with the next version.
[and IMO, you should not jump versions at all. 2 should be followed by 3, 4, 5, etc. Paying homage to Mozilla is not really a legitimate reason to jump versions]
The final version will not be 2.0. 2.0 was the set of betas from last year. For all intents and purposes, this is a new development effort and will be labeled as such. Anyone who 'vehemently disapproves' of a change in a version number is likely of the same camp annoyed at Chrome and Mozilla for their silly new versioning, but will get over it. It's a version number, not the apocalypse.
Sometimes, the impossible can become possible, if you're awesome!
You don't change people's opinion of your work by changing the version number, you change it by changing how you work.
In truth: people don't have a negative connotation of version 2.0, the real problem is with:
- Promised release dates that are missed by a whole year
- Long lead times and
- Lack of a clearly defined roadmap.
You need to get your development house in order and plan and publish a roadmap (without release dates), set up and use a subversioning system, and completely STOP making predictions of any kind about release dates - no more "in a few weeks" or even "soon".
Then, stick to your roadmap. When you need to publish a new version, whether it's a beta, RC or final release, don't tell people it's coming, just release it when it's ready.
Eventually, in a year or so, you will have established a new reputation of Reliability.
P.S. For the record, I think that you already have two great points in your reputation: Quality and Unimpeachable Integrity.
I made this half-pony, half-monkey monster to please you.
As I mentioned in the thread above, this is basically a new development effort independent of last year's betas. It will not be 2.0. We're just discussing what it will be. It's not going to magically wipe away all the lateness or any of that nor is it intended to. But it is supposed to signify a clean break with the past release.
I do not need to be told again of my failings. This is not the purpose of this thread. Consider PR1 a new day and lets move on from there.
Sometimes, the impossible can become possible, if you're awesome!
Sorry, my intention is not to make you feel bad; I thought I was offering constructive criticism.
In light of the last two posts, I will take your advice and reserve comment on that topic as it is a new beginning.
Also, considering you do not want to call the next release 2.0, then I will change my earlier vote and suggest that the next stable release be 3.0.
I made this half-pony, half-monkey monster to please you.
The title of this thread is "Platform 2.0 Version Number Change Discussion: Keep It, Change It?". If Keep It is not an option, "It will not be 2.0." the title is misleading.
Personally I think it should stay as 2.0. IMO You've worked too hard on it to dismiss it as a mistake.
Ed
I think the Ubuntu style "YY.MM" would be be good as it gives a very clear indication of when a version was released and the development period.
I would not encourage set date releases PA's development model works best with the "Ready when it's ready" style.
PortableApps.com Advocate
I see your point now, and I think 3.0 is the best out of all the options above. Maybe 3.0.11.07 (if you add the ubuntu style [last time I got confused with a different method])
Put simply, I do not want anything that purports to be in tandem with anything FireFox or equivalent.
3.14?
Cus this is SWEEEET!
Quamquam omniam nescio, nec nihil scio.
4.20 anyone?
It amazes me that on the internet you can be anything you want, and yet so many people still choose to be idiots.
I'd say to bump up the version number to 3.0. I know that 2.0 is out for too long so it maybe would be a good idea.
just use Mayor.Minor.Revision like normal applications use.
Bump Mayor with big changes, like new format for launchers and stuff like that, that make it (a bit) incompatible with previous versions...
Bump Minor when you add new features.
Bump the revision when you fix bugs etc.
And the fourth number can be used as build version build from the same source.
Don,t use year, as it'll can bite you in the behind. (Having in 2012 still use the 2011 version due to delays etc.
Ubuntu has a regular release schedule I think. Portable Apps (sorry I have to say it) still has to prove to make a release schedule and stick to it, so better not (same argument as year)
And a name? Meh, it has nothing to do with geeks, also 'regular' users will not know what version they have, or how outdated their's is. Besides, then you will loose time to think of names, voting for names, etc.
And just bumping the version number for nothing to appear higher... well, that might just be for a) you want to impress/mislead by showing version 10 while you only released 3 versions, or b) you want to catch up to the competition's version number because else the users might think the competition must be better due to the higher version number.
The official menu is 1.x.
Beta, RC or not, just release 2.0 (or heck 2.1 if you feel like it).
3 would suggest all the people who have been using non beta 1.x feel like they waited for a long time for 2.x and they missed it.
And please don't start with PortableApps 2012 deluxe gold pro edition a-la microsoft
2 releases in 2 days, who cares about the past.
We are being asked what we want in the menu, that is all that matters IMV.
I generally agree with the 2.0 thing, it should stay 2.0, however, I do have an opinion on why it should be 3.0:
You have worked long and hard on this software, it feels as though it should be at a 3.0 version, especially with the longevity of 2.0 pre-releases (which I appreciated having the ability to use.)
The naming scheme ubuntu uses is primarily because of their naming based off how long they support it, (3 years lts, 6 months all others I believe) so you know, 6 months from 11.04 (11.10) this will be unsupported.
ubuntu does not really need version numbers, because ubuntu is not being upgraded, everything that ubuntu includes is however, it's essentially a binder of software, and whilst we provide similar functionality, the platform serves a purpose larger than "binder." It is software in itself.
I think the general public has an opinion that because of how much software changes, all software should change that much, so you need to give the user a bit of security in the fact they are up to date.
On the about, include an "updated" date - the date of the latest release - this is probably the best idea in my wall'o'text.
use a Major.Minor.Hotfix. The reason I say hotfix, is because microsoft sneakily hides patches for bugs they never knew about under the name of "hotfixes" if you release app updates that fix bugs (e.g. purple pixels in platform preview) as a "hotfix" users feel a bit safer that the general platform is secure, and that such a patch may be for a special circumstance, or something quite minor.
just add one per each bug fixed, and if it gets to say, 20-50 bump up the minor version.
(Is it also possible to add to the updater "what does this update fix/do" a link or something? or maybe it grabs the text straight to the updater instead of opening a browser.)
Have minor updates be significant changes, either large bug fixes, or increment based off having around 20-50 hotfixes as I said before (2.0.37 is kinda odd heh, 2.1.7 is a little better.)
Major is as always a planned stage, "what should it do by version 4?" just please, you're not a web browser ushing fourth new standards, so please only add a major when major things are added, I consider categories not a major thing alone, categories and an app-updater? that's major.
my last bit would be - have pre-releases that are hidden by default that test features that would be added in the next major version
If you choose to use a minor as feature add, do it in a testing environment, since you want to make major revisions major, save feature adding to majors,
Either that or teach people a major update just means all the features have been added to the platform that constituted it being bumped up, regardless of whether you released a few of those features as a minor update.
if you want you can have a name, but my advice is is correspond that name to the version number something static, like portableapps 2.0 would be "Mars" 3 would be "Earth" something people can use to quickly show they have a newer version if they talk with other users (in this case, they'd need to know the order of the planets of course, but it's an example.) Put this little codename on the app menu itself, that and possibly add a right click to the top that has one context menu option "About Portableapps."
Pardon the wall of text folks, just adding my two cents to this quite large pile of pennies.
and yes, I am incredibly pointing out new features, they're only suggestions, I love this app John, and I only want to help improve it, I never expected such things nor will I, I literally just thought of them on the fly when thinking about version numbers, and wrote it down with it.
"Video games are bad for you? That's what they said about Rock'n'Roll." -Shigeru Miyamoto
There is much debate about the version number, but because the current version is 2.0pre2.1, it stands to reason that the final program version would be just 2.0
Regards BigBear
Yes, but using the number 3, would in effect break with the past and as the menu has evolved it probably makes more sense to clean slate (but not year).
You could always...
Roll a D6
nah, I like Ubuntu's methodology for version numbers, no guesswork. And you could give it a name as well, for the major releases within the same year thing.
I agree with 3.0.
I added in some more options, some realistic, some tongue-in-cheek.
Sometimes, the impossible can become possible, if you're awesome!
Why not copy iOS 4.2.1? It was supposed to be numbered 4.2, but Apple found a serious bug in 4.2, fixed it, renumbered it as 4.2.1, but marketed as 4.2 .
On the other hand, just use something like:
1.2.3.4 (r5)
1: Major version
2: Suite version (like Lite and Full in 1.6)
3: Minor version
4: Release
r5 (Internal) Build ID
So here's everything from the top
And that's the cosmic perspective.
Subjective comment on binary: By far, my favourite numbering scheme.
Objective comment: users will be confused by this, more so than any of the others, I figure.
[EDIT: Gahh!! Darn iPhone autocorrect! Grammar typo.]
You know what comes next.
I made this half-pony, half-monkey monster to please you.
Those who understand binary and those that don't.
The developer formerly known as ZGitRDun8705
To be honest, I was going to suggest binary, but he beat me to it.
But wouldn't that be tight? I mean, no other (legitimate) website makes (truly) portable apps. So we're unique.
And in my 31.4 seconds of googling it, I didn't find any other project that uses binary for versioning stuffs (some unix site mentioned similar binary versioning, but like 1.0.1 to 1.1.0 to 1.1.1 (101 to 111).
I withdraw my previous vote for 3.0 and put it in the imaginary ballet box for the next PAM to be 10.0.
I think we'd treat it as a one-time thing for this release and not continue in binary otherwise we risk seriously confusing users. 10 and then a point release of 10.1 is fine. But 10.1, 10.10, 10.11, 10.100 would confuse people. Same with the next major release as 11 would be fine but 10 then 11 then 100 would blow some people's minds
Sometimes, the impossible can become possible, if you're awesome!
I was talking about making the whole major release version from now on increment by 1 in binary. So after 10.x it'd be 11.x then 100.x and so on. Before you know it, we'll have 10,000 official platform releases (in binary, of course :P).
It was kind of a joke, but I still think it'd be interesting to see how people react to it
We should consider:
- Ancient greek (Attic) numbers
- Ogham Numerals
- Greek Letters - they can even go with names, e.g. α would be Asthmatic Alpaca
- Periodic Table (H, He, Li, Be, B, etc.)
- Zodiac Symbols
- Name them after PA.c Devs
I made this half-pony, half-monkey monster to please you.
"PortableApps.com Platform, Pyromaniac Edition, v6.6.6"
Known Bugs
EVERYTHING!
11.08 (Ubuntu style)
It's the best way. Anyone can tell if 11.08 is newer than 10.12, for example, don't mind if he knows Ubuntu rules of versions numbers.
So it works for both geeks and non-geeks.
PS: We will have some problem in year 3000, because version 00.xx will be newer than 99.yy even if 00 is less than 99. :lol:
RaphaelRB - Brazil
Ubuntu style is good... Only problem I have is that the US and UK change these around, coming from UK I have to say of course that the US is the wrong way around!
So perhaps to avoid confusion, use the FULL 4 digits for the year?
I think you can worry about the strange numbering problem in a thousand years! Will this platform, or any other currently around, still be in use then? Very doubtful! But... you never know!
Live for an ideal and leave no place in the mind for anything else.
Realistically, they're both wrong and YYYY-MM-DD is the way to go. If I can't text sort it, I don't want it!
Sometimes, the impossible can become possible, if you're awesome!
8) I forgot that year would be four digits long...
(Someone could argue that sort by date would do the same, but it would scramble every "Plan A", "Plan B", "Doc X" etc.)
RaphaelRB - Brazil
^2 (Squared) - I suspect this would lead to confusion for some people and doesn't really suffice your want to move away from the 2.x numbering.
3.0 (Just skip one) - This seems a very practical solution
5.0 (Monty Python) - Funny but guessing it will lose it's relevance following 5.x?
6 (Our anniversary) - So does this mean we jump to 6.x then 7.x afterward? Nice sentiment but...
6.0 (Mozilla homage) - Again nice sentiment but our release schedule will not be the same as Firefox's so will lose relevance after 6.x.
10 (Binary) - Funny but as versions get higher will becaome increasing difficult for most users to tell what is the current version.
10.0 (Multiplier) - umm... No.
X (Apple) - Please no.
11.08 (Ubuntu style) - My first preference. Easy to tell whats the most current version and familiar to many people as Ubuntu uses it.
2011 (Microsoft Office) - Not bad but as you said it limits updating within the year.
Names (Silly) - Wouldn't recommend as can't tell at a glance when released, etc. Maybe have a codename attached to a YY.MM as does Ubuntu.
PortableApps.com Advocate
It's larger than 2 and anyone of the mass public simply needs to know if the software their nephew/grandson/neighbor installed last year needs to be updated. Everything else is just added confusion around something that has no actual impact on the product.
Keep It Simple and Stupid.
We need it that way.
BTW, I'm still using the 'official' 1.x version, because I don't have the time required to find out just how stable a non-official release is.
Oh, and SWEEEET software John!!!
You made my life so easy.
Michael D. Shook
I suggest using a 'modified' Ubuntu style numbering.
The year should be part of the version number, however, instead of appending the month of release (which would lead to many timing problems as described in previous posts), I would use letters.
For example, the next release would be 11.A, 11A, 2011.A or 2011A when major or minor changes take place, the next version would be 11.B or 2011.B, the one after that 11.C or 2011.C -- I guess 26 letters should be enough for any number of modifications the platform could have in a year.
This would help in continuously numbering the versions (year) and differentiating between incremental releases within the same year without tying a scheduled release to a specific date... and missing it.
ANOTHER option would be to simply use "Build" numbers within each year.
Next version could be 1101, then 1102, 1103... with the first new major or minor release in 2012 being 1201... no dots between numbers so nobody mistakes this numbering system with months or otherwise.
I like the Ubuntu style of numbering for major releases as it's easy to track the version age but given feature creap can be an issue for PA I'd suggest 11.08.00 for the first stable release then add to the final group for minor updates/bug fixes etc 11.08.01 until the next major stable release is ready. Perhaps 12.07.00 would be next.
For the curious, if we did do 10 as the next version (because it's 2 in binary), we wouldn't then do 11, 100, 101, etc. We'd just go back to normal versioning. Decimals especially would get really confusing.
It's important to keep in mind that we'll likely have another major version release within a month or two for another high-profile feature we'll be adding.
Sometimes, the impossible can become possible, if you're awesome!
Don't you mean another Pre-Release?
There's nothing wrong with going to release 10 binary then switching to 11 decimal. The releases would still sort sequentially. And considering how long it's been since the last real release, 1.6, I don't think anyone will remember the binary switch when the next release comes along.
Ed
I mean after we do release 10 (or whatever we call it), we'll be working on another update shortly after which will get a major version increment to 11 (or similar) due to a couple big new features. We'll, of course, do a test version and it'll be 11 Pre-Release 1 (or similar). We'll also be letting people switch from the stable platform and updates to the beta 'channel' and updates similar to Google Chrome with a simple checkbox in the Advanced section of Options.
Sometimes, the impossible can become possible, if you're awesome!
If 11 will be that close to 10, or even this year, then I suggest you finish 2 as 2 then go to 3 or whatever numbering scheme you like. You've worked a long time on 2, I'd hate to see it be a failure, which is what changing the number would imply.
I'm a big believer in finishing what you start.
Ed
Doing another major release because you introduce a great new feature doesn't somehow make the last major release a failure. It's just that the platform is now getting a lot more development-love than it did previously and we're speeding up the dev cycle to early and often. The features we're going to add for the next major release haven't even been mentioned publicly yet. And I'm not talking about 11 (or whatever) coming a week after 10, either. Shortly means a couple months or so before it 'goes gold'.
Sometimes, the impossible can become possible, if you're awesome!
Release this "current" platform, or something similar, for like a week, as 2.0, and then have 3.0 PR1 (or b1 or whatever) follow 2-6 weeks later. And then continue from there.
I support Pyromaniac's idea.
Ed
Hi John,
I'm a fan of helping users of the platform glance at the version number and know, without thinking, whether they have the most recent version.
Most of the ideas here are needlessly confusing to end-users: skipping forward in the sequence, naming releases, synchronizing to other platforms, referencing Monty Python, and using exponents. These are clever but the value is questionable.
As others have suggested, the apple iOS system is a good model: 4.11.1, 4.12.3, or whatever, major.minor.bugfix. My grandmother could tell which is the most recent. She doesn't need to think about whether they've met their release dates, or bug fixes. And she can even tell which version to revert to if she has a problem (even if she doesn't know how to do that).
Since this is a major change, I'd like to see you bump it up to 3.0 and continue from there.
But please keep it simple. The Portable Apps Platform has enough levels of complexity without getting tied up in knots over version numbers.
Best,
Phil Honstein
Stuff like naming and exponents was a joke just for fun. As was binary for all releases (even we do 10 for the next version since it's the binary version of 2, we'd still follow it as 11, 12, 13, etc). We're gonna have a simple version sequence that anyone can follow from the next release onward just as we always had. We're just skipping "2.0" and gonna jump to something else, that's what this thread is about.
You don't really think we'd go 10, 10.1, 11, 100, 100.1, 100.10 or Happy, Sneezy, Dopey, etc do you? That'd just be cruel!
Sometimes, the impossible can become possible, if you're awesome!
Apple has done that, right? Does a Jaguar come before or after a Leopard? A tiger before or after a Lion? I'm sure god, or jobs, must know.
Best,
Phil Honstein
One more thought...
I would think that jumping to 10, while very clever, both misleads and confuses. And to what benefit?
Best,
Phil
I have always been a fan of the version format (Major.Minor.Build). This helps with know what the current version is and the build numbers show the incremental updates in the Betas and PRs.
Whatever we decide on next, we will have 3 digits with one fourth one internal (or 2 with one internal)
Sometimes, the impossible can become possible, if you're awesome!
An option to consider is that traditionally when purchasing software you got free upgrades within the same version number. So, I buy 3.2, I get all 3.xxx upgrades free, but 4.x is gonna cost me an upgrade purchase. So it's easy to keep track of what I can do for free, and when I have to pay. Also traditionally, when the developers feel that there has been enough effort to build a version of software that their managers / marketing dept. want to get paid again, they call it a new version to trigger the purchasing of new upgrade licenses.
However, since this is freeware, these reasons are now bunk. Yes, bunk I say. The decision to upgrade is now completely up to the user. There are only three reasons for me to upgrade: new features that I may or may not use, bug fixes I may or may not care about and loss of support for old versions that I may or may not need.
So the use of versions can help here too: New feature set is denoted by larger first number, new bug fix for feature set of existing version is new or larger second number and finally a statement clearly made on the front page of this website saying "We only support versions x through current". (also perhaps have the software always check to see if it's too old and pop-up a reminder that it's now non-supported).
Yes, I said "new feature set is denoted by larger first number". How this works is at the first dev meeting after the last release the management reviews the potential new features and chooses a set that will become the "feature set scope". This creates a definate list of what will be in the next release. This can be a single new feature if it's significant enough, or a set of smaller features. Either way what's important is being able to say "The next version will have these new features:" and then stick to it!!!
This also means you will tend to burn through version numbers. But that's OK, since it doesn't cost me anything.
So what you're left with is version/bugfix(/build) = very simple and easy to track.
Michael D. Shook
An option to also consider to assist keeping track of beta/PR/dev etc... If you do a major/minor/bugfix(/build) schema you can also use the evenness of the minor or bugfix level you advertise to denote that the software is in non-gold / pre-release / unstable testing:
3.0.0 = Stable
3.0.1 = first bug fix working version released to the 'inner circle' for QC
3.0.2 = first bug fix released to masses as Stable
3.1.x = first minor version working version released to the 'inner circle' for QC
3.2.x = first minor version released to masses as Stable
We get consistent versions to know when/if/how much to upgrade, you and the developers get consistent internal versions amongst yourselves.
Michael D. Shook
I vote "Keep it!" 2.0, as the current version numbers lead one to expect.
At this point, with as stable as you (meaning all the devs) have gotten it, I would really say make the very next release 2.0 final, not RC anything. Or, if you really want to show that this release is so different than what was previously planned, call it 2.5. But, just don't keep calling it RC++. Most X.0 releases of even major "enterprise quality" software have a list of known bugs, with a minor update not long after release, and my experience leads me to believe the current RC is at least as good quality as--if not better then--most X.0 releases of major, well known software. Then, with the 2.X branch capped with a "final" release, you're free to call the next version with any noticeable feature introduction, such as what you mention will be coming "shortly" with a couple big, new, previously unannounced features 3.0.
Although you were correct when you said,
the 2.X line doesn't yet officially have a "last major release" (at least in public perception--meaning with an official 2.X non-RC), and moving on without one could give that negative implication some people are worried about.
I also suggest keeping only the major.minor release numbers showing on the download button, splash screen, title bar, and just about anywhere else that is for public consumption, with the unique update.build identifiers showing on the about screen, source files, and fine print on the production information Web page on the PA site. Additionally, use yyyy.mm.dd.build for the hidden part, so those who care can get the info. So, for a hypothetical Christmas Eve update, the full version number might be 3.1.2011.12.24.4269, with only 3.1 showing in most areas.
This way, bug-fix updates don't need to change the publicly noticeable number ahead of plan--unless it was a major / well known / wildly hated bug that you want to show a break from by changing the "minor" number, such as from 3.1 to 3.2.
Maybe a feature introduced in some 4+ release could be a title bar that indicates the last time updates were checked. For instance, for a hypthetical release 4.3.2012.07.01.6942 where the user last checked for updates on 2012-08-13, the top of the PA Menu would read as follows.
I've enjoyed the fruits of your work since before PA 1.0, and I now use the latest PA for work on a daily basis.
Thanks for all the work you've done and continue to do. I'm looking forward to what you've got in the works.
Zephyr Riley
are you gonna put up a poll like you have in the past, with radio buttons and such? I'd like to see that again.
Good Afternoon Group;
I think jumping to three would be a good idea. A suggestion was to add some other numbers to it like a build number or even a ".01" or more.
I would like to suggest that a year number would not be a good idea. People seem to go nuts about things being to old with no updates.
Another suggestion would be not to annouce a expected release date. I thought some other Software says something like "we are pleased to annouce the release of "XXX" after it is actually released. Until you reach a point where you can release a new one do not and just call it what ever you want and add numbers to it as you release a fix to be tested. May be sommething like LO does with a test version and a stable version it does not really matter as long as we know what it all means.
The last is a suggestion only. I like the last stable release and do not care how old it is. But others are not as flexible perhaps. PA may be free to use but it is not to maintain. I also like that with the stable releases I have not had problems. So feel free to take your time and do it again. Think about the after the fact annoucement it may take some heat off of the developers and you.
Frank D. Hubeny
Pages