I would prefer the following:
1 month n-month (n+1)-month
--\---- devel-----\----...---\--------------\-----....----\-->
\ \ \ \ \
release 1.2 --------....---\ \ \
\ \ \
release 1.3-------------------->
Have one current stable and one devel branch. No support
for older versions. You can do this if you have enough man
power. Which we don't have at the moment.
I would vote for short merging intervals (1 month or so).
Such a merge brings the current release to a new second digit
after the stable version number (1.2 -> 1.2.1). If we think
its time for new major release we can increment the first
after dot (1.2 -> 1.3). Having the devel and the stable
branch coupled so tightly helps us to fix urgent bugs in time
and develop new features. But the development/release model
should not be set in stone. It depends on the man power
(which hopefully will increase). All it have to be is
that has to be transparent to the users.
- Sascha
Michaël Michaud schrieb:
> Hi,
> I can see several ways to manage stable/development versions (mainly
> depending on how much effort we can put in maintaining all the stuff -
> not much until now).
> Hope my ascii art will be readable
>
> 1 - The most simple (CVS must be always clean and releases are
> done after a period where every developper concentrate on tests and bug
> fixes)
> -----------------------------------------------> Development version (CVS)
> \ \
> release 1.2 release 1.3
>
>
> 2 - Stable versions are derived from development CVS as needed
> (bugs fixes are done on both branches during some weeeks, but the
> development
> branche is ging on without threatening the stable one)
> -----------------------------------------------> Development version (CVS)
> \ \
> ----------->1.2 ------------>1.3 Bug fixing
>
> 3 - Two branches
> (needs to take new developments of the development branch, to
> backport them and to test them in the stable branch)
> -----------------------------------------------> Development version
> \ \ \
> \ \ \
> Syncronization work
> -----------------------------------------------> Stable branch
>
> It seems to me that we have not enough development resource to do more
> than [2], but I'm not a professional developper, and I may ignore how we
> can organize ourself to have a stable branch and a development branch
> without loosing too much energy.
>
> My two cents
>
> Michaël
>
>
> Stefan Steiniger a écrit :
>
>> Hei,
>>
>> hope it is ok to send a copy on the list.
>>
>> I am not sure about it, since it doubles efforts in copying and
>> syncronizing the sources and i think nightly builts have to be somehow
>> stable (i.e. are runnable)
>>
>> What would be possible is to make a new tree from the current module
>> that contains the "stable" version. While the current cvs versions stays
>> would be the instable one.
>>
>> Because i would not like to loose the nightly built. This would ensure
>> that changes made are still one day afterwards avaliable to users.
>>
>> other oppinions?
>>
>> sorry if i missed some of the emails that dicussed that issue - simply
>> to much are coming in at the time.
>>
>> stefan
>>
>> Sunburned Surveyor schrieb:
>>
>>
>>> Stefan,
>>>
>>> It sounds like a couple of the developers would like to have an
>>> unstable branch of the OpenJUMP code base that they could work in.
>>> Would you have a problem hosting this in the OpenJUMP CVS?
>>>
>>> If you have reasons to avoid this I will create a copy of the OpenJUMP
>>> code at the SurveyOS that can be used instead, but I think it would be
>>> easier to keep the two branches in the same repository.
>>>
>>> Let me know what you prefer. I can let the list know about our
>>> decision and make the changes needed.
>>>
>>> Thanks,
>>>
>>> Landon
>>>
>>>
>>>
>>>
>> -------------------------------------------------------------------------
>> This SF.net email is sponsored by DB2 Express
>> Download DB2 Express C - the FREE version of DB2 express and take
>> control of your XML. No limits. Just data. Click to get it now.
>> http://sourceforge.net/powerbar/db2/
>> _______________________________________________
>> Jump-pilot-devel mailing list
>> Jump-pilot-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>>
>>
>>
>>
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> Jump-pilot-devel mailing list
> Jump-pilot-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
