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?
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.
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.
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?
Please go ahead and commit the patches.
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.
Ok, add .t support.
Support for .t files would be excellent.
I keep adding it to my Eclipse config each time I setup EPIC on a new machine.
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.
oh - i may also be able to provide hosting for things like an automated build, etc that could then be published for download.
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.
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.
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. :)
Log in to post a comment.