Release Schedules and Feedback on Fixes

[Robert Brenstein]

>Yes this wish is clear.
>But take into account this my reason which have keep me also to avoid this.
>
>1) you say about YOUR app branches. Good. Clear.
>     but you make and support this one app.
>     so on your site exists only few archives:
>
>         1.0  -> 1.1  ->  1.2
>         1.5

I don't don't whether Joakim has one or more products but he is 
certainly only one of many developers affected by this. Ruslan, let 
me say it this way: Valentina is not a desktop application but a tool 
used by developers. This puts an extra burden on you as you need to 
content not only your product development but also our product 
development.

We are not saying this to annoy you. I have used FileMaker and have 
been using MySQL, but Valentina is still my favorite database and I 
would like for it to flourish further. And I truly believe that both 
you and we will benefit from branching on the long term.

>
>2) the same with FileMaker I think, example of Robert.
>     they make SINGLE product with single archive.

Well, FileMaker has actually 4 products in the lineup: Pro, Server, 
Developer, and Mobile, each for Mac and Windows. They used to have 
some of them in a few different languages, but I see that now is only 
English.

>
>With Valentina we have about 15 archives of all products and ADKs in full
>product line. It takes at least 5-6 hours to build all these archives using
>at least 2 computers.
>

But if I am not mistaken, the core program is the same with some 
wrapper for each ADK. More or less. I know that this is a bit more 
complicated. You also must have a series of makefiles that are 
running the product production. Such a project begs for cvs. Such 
projects are what cvs was invented for.

>Total upload now takes about 200 MB.

I presume that 200 Mb is the total size of the downloadable products. 
That is not that much really. Server space is so cheap these days 
that I don't see this as an issue. I pay $8/mo for 6 GB and this is 
not even the best deal around. 6 GB is enough for 30 archives of 200 
MB each. That is 30 branches. How many public releases have we had in 
V2 so far? A simple strategy would be to keep the current public and 
development branches on your main web site and have a link there to 
"older releases" which are kept at some other host which gives you 
lots of storage for little money. You won't even need much bandwidth 
there.

>So when I think about way to keep on site full product line for 2.5,
>Then do releases 2.6 and 2.7, then 3.0
>and be able yet return back and produce 2.5.4 and upload it ...

No, Ruslan, you don't read or fully follow what we are saying. :-(

If 2.7 is the current public release, nobody will expect you to make 
any new builds for 2.5. The beauty of branching is that you will 
continue to develop pretty much just as you do now, but we won't be 
so directly affected by that as we are now. Your release cycles will 
extend, though.


>This looks like too titanic job for such not big team as we do.
>But we will try of course, may be its not so scary and hard :-)

I think it seems more scary and hard than it is in reality, although 
admittedly, the initial changeover will require real effort and 
planning. But look at 130k+  the projects at SorceForge running under 
cvs or subversion. It is not rocket science. Granted almost all 
SourceForge-based projects produce a single product but Valentina 
family is essentially a series of products with just some common 
parts.

Go to SourceForge and read docs E04 and E09 to get an overview.


>---------------  
>We discuss this here, and Ivan says:
>     in ideal - to provide all this, we need yet at least
>
>     * one more developer which do only job - build archives from CVS.
>
>     * second developer-manager do manage only CVS, think and plan
>     branches, bug/features separation into branches,
>     fixes propagation in branches
>
>I just expose our thinks aloud  :-)
>I'd add
>
>     * full time tester-developer, which do only job as get from
>     CVS sources, to MAC and WIN, build tests and run them, as often
>     as possible.
>
>This will almost double requirement for our team :-))

Sorry, but this is all rubbish to say it bluntly. You don't need to 
build archives from CVS. CVS is your archive.  Historical archives, 
which you put into a vault, will be copies of cvs backups or hard 
drives with complete compile configs (hard drives are so cheap these 
days).

Planning branches? They just happen as they have been happening all 
the time. Nothing extra to plan. And certainly no extra person to 
think about them.

Full-time tester is fine but not on account of CVS. CVS does not 
change the way you develop and test, it just changes the handling of 
files in the process and gives you easy means of parallel development.

Propagating fixes will be the task of whoever fixes the bug and 
checks it in. He is the one that can resolve any potential conflicts 
most efficiently and knows when the fix is committed and tested. 
Involving extra person would be waste of resources.

Ruslan, you seem to think that cvs will be something extra to do on 
top of what you do now. In reality, cvs should and will replace 
and/or modify what you do now.

All you need is to setup a decent server for cvs or subversion or 
whatever versioning software you choose, with raid and external 
backup system. One-time setup effort, and then it runs pretty much on 
its own, with ocassional system and cvs/subversion upgrades, of 
course. All your sources are on that server. The storage is very 
efficient because cvs stores diffs. Each developer checks code out 
for working and in when they are done. Checkin's automatically 
document the code changes. It does not matter whether your team 
members sit in the same room or are at different locations. The 
computers used for building actual ADK's just update their local copy 
of files from that server and then run compiling and linking. This 
can probably be also automated.

It seems to me that the biggest effort will be for you and your team 
to adjust to the cvs ways of thinking and functioning and set things 
up to get moving.

Most developer tools, including Xcode, have hooks for working with 
cvs and subversion. There was actually a nice, basic introduction to 
cvs in Oct 2006 issue of MacTech magazine and intro to subversion in 
their Nov 2006 issue. Check them out. If you don't subscribe to 
MacTech, I can scan these articles and send to you. They describe 
both pros and cons so you get a good overview.

Robert