Next release of EPIC

jploski wrote on Thu Aug  3 01:07:56 MEST 2006:

Hi,

I now have the necessary permissions (thanks, Jochen) and sufficient time
to prepare the next official release of EPIC. The plan is as follows:

1. The current CVS version, known as epic-devel, becomes 'stable' (feature
version 0.4.0) and 'testing' (v.0.5.0) at the same time.

2. A CVS branch 'stable' is created in each plug-in, with the intent to
commit bug fixes to both 'stable' and 'testing', but new features only to
'testing'. This means extra work and entry barriers for new developers,
but I think it is necessary. I am particularly worried about refactorings
- these will likely have to be performed on both branches to keep them close.

3. epic-devel ceases to exist. Updates will be delivered through the update
sites and through the regular sf.net downloads interface (if this process
can be sufficiently automated).

4. The rightmost part of the version number will be increased each time
when changes are made available through the update sites.

5. In the future, the 'testing' version might be declared stable at some
point. In this case, it will get the version number 0.6.0, and the new 'testing'
will get 0.7.0.

6. I am going to start a docbook named 'EPIC Developer's Guide' in the plug-in
org.epic.doc, as a central place for information for those who wish to become
involved with the project. This will also be published somewhere on the
web site.

7. The web site content is put under CVS in org.epic.website and can thus
be improved by any EPIC committer. Some parts of the web site, such as the
update sites and documentation will be generated from content contained
in the other plug-ins. My role will be to release the changes.

8. I am going to close many (most?) bug tracker items - both the fixed ones
and the ones which seem very old and no longer reproducible.

As far as the actual bug fixes and new features after the release are concerned,
I do not have any grand plans and would instead welcome contributions from
the community at large (that's you :-).

Do you have any comments, requests, or advice at this point?

jgangemi wrote on Thu Aug  3 06:43:33 MEST 2006:

what are the plans for the outstanding patches? will those just be put off
until the next version?

i'm committed to investing further time in development, so let me know what
i can do to help.

jploski wrote on Thu Aug  3 13:40:16 MEST 2006:

The patches will wait until after this release. So they will likely make
it into 'testing', but not 'stable'.

I'd like to have a build.xml with two targets, which create the update sites
inside of the org.epic.website project (for 'stable', and 'testing'). This
way, any developer can run these scripts and commit org.epic.website to
CVS in order to prepare a minor update. The remaining part, which I have
to do myself, is running 'cvs update' on the web server.

I foresee a lot of such small updates - just like they used to happen for
epic-devel. My goal is to make them technically doable in a matter of minutes.
As far as the next switch from testing to stable is concerned, I think it
will take several months, and might then require a release freeze.

The more users go with testing, the easier this switch will be. Hence, broken/incomplete
code should be committed to neither 'testing' nor 'stable'.

At this time, I don't think we will need external hosting. The infrastructure
provided by sf.net has poor performance, but otherwise fulfils its task
pretty well. It would be interesting to investigate whether the sf.net mirroring
system can be adopted for the update sites, though.

jgangemi wrote on Thu Aug  3 14:27:28 MEST 2006:

i would at least commit the ScriptExecutor class patch since the source
formatter doesn't work correctly w/o it (the patch fixes the path lookup)
and maybe the one that fixes a formatter option.

the breakpoint patch is rather a large change, and would probably be best
left till afterwards. 

the hosting option was for nothing more then automated builds, which i didn't
think sourceforge could provide. it can always be re-evaluated at a later
date.

do you have a time frame for all of this?

jploski wrote on Thu Aug  3 15:22:46 MEST 2006:

Please go ahead and commit the patches.

jgangemi wrote on Thu Aug  3 15:50:43 MEST 2006:

woohoo! i'll get them in later today.

while we're at it, do you have any objections to including .t support in
the next release? all this requires is a small modification to the plugin.xml
file to add the extension.

jploski wrote on Thu Aug  3 17:40:48 MEST 2006:

Ok, add .t support.

matisse wrote on Fri Aug  4 18:26:35 MEST 2006:

Support for .t files would be excellent.
I keep adding it to my Eclipse config each time I setup EPIC on a new machine.

jgangemi wrote on Fri Aug  4 18:48:26 MEST 2006:

added and should now be a part of the 0.4.0 release.

watch for double click toggling of breakpoints to land in 'testing' some
time this weekend.

jgangemi wrote on Thu Aug  3 06:47:14 MEST 2006:

oh - i may also be able to provide hosting for things like an automated
build, etc that could then be published for download.

jgangemi wrote on Thu Aug  3 16:07:16 MEST 2006:

after further though, i'm not sure i like the 'testing' branch name, b/c
to me, it implies a release that is being tested for release.

why not use 'stable' and 'dev' branches instead, and then use a 'testing'
tag on the dev branch when it's time to get a release together. what about
a stable bug fix branch as well? or i guess a better question would be what
will HEAD reference? my 2 cents is that it should always point to the current
stable release source, which is where the bugfix branch would come in.

i also see your concern about refactorings, but i'm not sure that's going
to be practical. there definately shouldn't be any major changes between
'stable' and 'stable-bugfix', however after that, nothing is guarenteed.


if a developer is working on a certain piece of code in 'dev' that a 'stable'
bugfix patch is submitted for, that developer should apply the bugfix patch,
and then should have no problems working the solution into the refactored
code on the 'dev' branch.

jploski wrote on Thu Aug  3 17:16:04 MEST 2006:

HEAD = 'testing', plus a separate branch for 'stable'.

Your interpretation of 'testing' is correct and intended. I would not like
'testing' to become a 'use at your own risk' sort of branch for the brave.
The code committed there should have been tried out by the committer, have
unit tests etc. I believe that continuous integration is a better development
model than cumulated testing efforts before a release.

If someone needs to work on experimental code for a longer time, I'd suggest
a private branch.

The concern about refactorings is mainly about the tool support. It is possible
to pick up bug fixes from 'stable' into HEAD manually, but there is little
hope for a CVS merge when HEAD has been refactored and 'stable' has not.
For that reason, I tend to think that refactorings should be performed concurrently
on both branches (they don't change functionality = don't introduce bugs,
right? ;). I guess time will show which way works.

jgangemi wrote on Thu Aug  3 17:41:08 MEST 2006:

private branches should address most of the "bleeding edge" issues, and
i don't see any reason two ppl couldn't work on the same private branch
at the same time if needed.

and isn't a "replace" of refactored code into 'stable' the same thing as
a merge? 

you're right that time will tell what works best, and it shouldn't really
even be an issue until we reach a point where someone is refactoring code
gets a bug fix submission. at some point what qualifies as a fix that should
be applied to 'stable' vs what will just come out in the next release.

reguardless, unless there is a sudden deluge of patches submitted, i think
we'll be ok for now. :)