News: Notes on the releases

Hello guys,

this post is going to be about our release policy. Some people here, are aware of the policy and philosophy, but some are confused. Many people, whether here on the forums, or directly by mail, have asked when we will release 1.0. The answer from us always the same: we don’t know. The thing is, that, after several missed release dates and estimations, we moved to feature-based planning. Our roadmap has no dates, just features and versions. I will publish current roadmap soon, but until then, I’d like to make clear what stages are waiting for us. Currently, as you know, we are in alpha stage, constantly moving towards beta stage. But what does it mean?

Well, the current alpha stage means for us building of features. So we are planning, designing and implementing features along with fixing them. The crucial point here is to keep stability on the highest possible level, to give you more pleasure of testing by using, not by trying. We ourselves are still trying various changes of the development cycle. Our latest, and most important, change is to limit the feature count for each release. The 0.3.5 is last of the big releases, because we are changing the background UI-layer and also implementing features to keep up with the roadmap. So when you get 0.3.5, it will be like getting 0.3.2-0.3.5 versions pointed in a roadmap. After the 0.3.5, each minor version (milestone) contains a little set of features, so the release rate will significantly increase. After the alpha, the beta comes.

Now, somebody may think, that with current rate of delivering the milestones, there is going to be 65 more milestones (from 0.3.5 to 1.0.0), but that ain’t true. By the current roadmap, we will be entering beta stage at 0.5.0. The beta stage means, that we will stop adding more features (only those really needed, nor considered yet) and this is where the pre-payment comes to the game. The beta stage should be a short one. We will implement all pending optimizations over all the features, and keep removing any bugs you may come to.

And after beta, 1.0 is here. This is where we are now heading to. However, it does not mean that we are going to stop. There is a whole bunch of features planned up to 1.5 all based on the current code, so no global changes (as changing the UI backend) are planned (we have to do global changes now).

Now: *Why oh why is development so slow?”. It is not slow, actually. Many of you currently love how Intype is fast, simple, and powerful in comparing to our competitors. This approach requires many design cycles, mockups and discussions. Also, we like to have the beauty not only on front-end, but also in the code itself. So every time we find something that can be changed, that can give us a lot more maneuvering space, we go for it, and we squeeze as much juice as possible. The same is happening to 0.3.5.

I hope that you are going to attend our discussions here, in News section, and give us your opinions on features we are about to implement.

Thanks for info on team’s plans, martin.

Intype is fast, simple, and powerful in comparing to our competitors

Fast and simple, and even beautiful, but not as powerful as competitors: both E and sublime text editors have scripting support. This is the one feature I wait from Intype.

About release policy. Just look on releases of sublime text, one of your competitors. Author doesn’t give time estimates for releases, but every week we have at least one beta, and it gives users understanding on what are current plans, development speed etc. E has similar release policy. And this doesn’t contradict to “many design cycles, mockups, and discussions”. Quite the contrary – users get involved in this process.

I’d agree with that – unless you visit the forums and get the releases RSS, you would assume that Intype had been abandoned for a year or so – it’s looks dead from the outside, unless you come here.
All it would take would be to put stuff like this on the blog as well, maybe with comments switched off and a forum link, if you’re worried about splitting the discussion. Then make sure that the blog feed on the frontpage picks it up.

bael mvm Ingwar dflock & cammm: Many thanks for your support. We plan to open the blog again soon.

mvm: I don’t really enjoy comparing to competition (I was just summarizing opinion of the community) — I feel we are different in the philosophy and attitudes in many development aspects. The thing that we have to work is to merge our style with your expectations. There is one thing I forgot to mention in this post, that is really important (shame on me). We are planning to merge the Unstable and Stable branches to create one primary et recommended branch. The Unstable releases are rarely unstable, and if, the fix is available within days. Together with merging these two, we will publish the Cutting-Edge releases, that are similar to what you call “weekly builds”. We’d like to do a test drive with 0.3.5 and full drive with 0.4 (together with a new site).

I totally support ingwar in this. I do software development too and I know it is extremely difficult for a small team to keep up with the community, but you see it is essential. I mean, we are here and give you a vote of confidence by keeping in touch with the project. Perhaps you should try and hurry up that presale stage and maybe those money (I;m in :) ) will get you a web editor that will revamp this community website.

baael: As it’s affected by many other things in our lives, I don’t like answering such questions. However, end of July seem to be the best guess from current state of the implementation for having 90% of 0.3.5 ready. This release will be marked as 0.3.5 Community Preview 1.

Just dropin’ by, I’m very much excited for the 0.3.5 release. 20 more days to go…

I’m a PHP and Rails developer and I’m using Intype both at home and work. It’s so neat that it makes me feel very good in programming. :D

Yes, Keep the good work guys!

for me intype.info is one of the sites I check every day to see any news. I am an e-text editor customer that really really hopes intype gets to 3.5 ASAP and has those promised and very good features.

I like that intype is rock solid and i think for an editor this is crucial. When you are in the “zone” writing error free code :) and bam the editor crashes it really kills your mood.

So i can put my money in this intype business. For if it maintains the standard as it is it will be the de facto editor for WIndows.

yahh!

It’s been a while since I’ve posted (thanks to my macbook pro + textmate). But the release policy is an important and often critical aspect of software development. I’ll go as far to say that a product’s success depends on it. That is especially true for InType. We’re using these products for hobby projects and in production environments (whether you suggest it or not). Like Ingwar and many others have been saying, it’s not really about competition comparisons, but its about involving the community in the process and that means a frequent release cycle. Pleasing us isn’t the goal, making a solid, well tested, high performance product is the priority and I think you already know that.

I develop software doing mostly user interface work and we deploy a release every week no matter what. Of course we make sure stuff isn’t broken, but having 2-4 weeks of bug fixes isn’t abnormal, it’s welcomed more than anything. So +1 for a rigorous release schedule.

Lindblom: Again, thank you a lot for the support. As in our general plan, we’d like to stick as much close as possible with Windows and enable user to take advantage of it’s technologies. We will also consider working with PowerShell, it’s in our plan for a long time.

i feel guilty for my question (18 June) ...