I like the idea of a native Linux email client. The UI looks pretty good too. It's really not hard to beat thunderbird.
Calling it version 1.0 is bullshit though. It's only about a month old: https://github.com/c9dev/penguin-mail/graphs/contributors?al...
A project with the complexity of an email client cannot be considered stable in a month. There are bugs that will only show up after a year. It has a calendar after all.
I don't understand this mentality. It's an email client. There's not a lot needed UI-wise to make a functioning interface. Display a list of emails, show the full message when you open it, etc. I don't see anything functionally different between this email app and basically every other one I've ever used.
You've either got insane standards or are using email way different than I.
But from a normal user's standpoint? I don't care. If my email client needs more than a single thread, something's fucked.
I randomly bounce between Thunderbird and KMail and honestly I can't tell the difference except cosmetically. Both are snappy. Neither crash. Both send and receive emails just fine.
I know things like that don’t bother some folks and that’s fine, but others like myself can’t turn the visual parts of their brains off and so some software feels like nails on a chalkboard to use.
That might be the most accurate description of Thunderbird that I've come across. It's hard to pinpoint exactly what's wrong with Thunderbird, despite me using it every day. Somehow it feels like the emails aren't the important bit of the UI, but I also couldn't tell you what I'm looking at instead.
I often find myself in situations where someone wants to break the UI I like, because they're used to something else.
It seems that most of the time, "feels right" just means "it works like I'm used to in other software". So: GMail, Outlook, whatever. Which is sad.
I wonder how would you react to "TheBat!" or Pegasus Mail?
Glancing at screenshots of TheBat! and Pegasus Mail, i don’t find them objectionable in the way I do Thunderbird. They’re just old school desktop clients like I used in the late 90s/early 2000s, which I generally find workable. They’re not quite my preferred style these days (which falls into the “it’s not what I’m used to” bucket you mentioned) but I could probably get used to them again if I had to.
Thunderbird on the other hand feels wrong somehow, and the recent UI “modernization” didn’t do much to change that.
I don't understand this mentality.
Human communication is one of the most complicated activities in existence. Most (all) clients are modelling it very poorly.
I remember waiting for ~15 years until Thunderbird finally implemented rich content support in the e-mail list (needed for a proper 3-column layout, as otherwise the e-mail list, being a simple table, wouldn't fit on the widest screens available).
So, yeah... Not a lot, but Thunderbird has been missing the bar for over a decade.
2. Seems odd to assume instability by default without evidence.
If so, I'd love to hear a writeup!
It's missing some features that are dealbreakers for me, but I haven't found anything unstable yet.
There is a case to be made to always start at 1.0, especially libraries with public API’s. The reason is that if you use semantic versioning then below 1.0 you can’t properly declare a new release to be a feature or bugfix release (for example, 0.4 to 0.5. Is this bugfix or feature?). Above 1.0.0 this is easy (for example 1.1.0 vs 1.0.1).
Naturally, the users should treat those libraries as beta versions and only use them in production at their own risk.
> you can’t properly declare a new release to be a feature or bugfix
0.5.0 vs 0.4.1?
In practice, 0.5 can be assumed to be breaking but then how do you specify non breaking new features? 0.4.1? Moving to 1.0.0 makes things a lot clearer. For breaking, just go to 2.0.0 etc
You don’t. As soon as you feel the API is stable enough, move to 1.0.0. 0.x is for the “yeah the API doesn’t feel right just yet but it might be useful for early adopters” stage.
I know there’s the tendency for mature projects to live in 0.x for a long while, yeah – definitely try to avoid that. But 0.x is a useful first step for libraries, especially if the API is non-trivial.