On Apr 13, 2010, at 12:00 PM, Scott Gray wrote: > On 13/04/2010, at 9:36 PM, Jacopo Cappellato wrote: > >> On Apr 13, 2010, at 11:33 AM, Scott Gray wrote: >> >>> Hi Jacopo, >>> >>> What exactly does it mean to create an "alpha" release, compared to what we >>> have now where we create a release branch? >> >> It fundamentally means that we can distribute it outside of the inner group >> of contributors because the we can guarantee that it is full compliant with >> ASF license requirements. > > Ah okay I see what you mean and that sounds fine to me. I'm not entirely > clear on the version numbering though, 10.04a, 10.04b, 10.04 (this is the > stable one), 10.04.1 (post stable bug fix release?) >
Numbering is an interesting point because it is difficult to state what is "stable" from what is not; in your example, of course 10.04a is not stable; however what makes 10.04 stable? In fact it is less stable than 10.04.1. I don't know, if we are concerned about clarifying what we consider stable we could follow the following strategy: adding the prefix "alpha-" to all the releases we feel like should not be considered "stable". For example: alpha-10.04.a alpha-10.04.b Then when we feel we can consider the release stable: 10.04 (first stable release on 10.04) 10.04.1 (latest current stable release on 10.04) or even: stable-10.04 stable-10.04.1 Even if it could be simpler to just start from 10.04.1 since the first alpha release and then continue increasing the suffix: alpha-10.04.1 alpha-10.04.2 stable-10.04.3 stable-10.04.4 but I understand that this is less appealing (i.e. the "stable" release will start with 10.04.3) Jacopo >> >> Kind regards, >> >> Jacopo >> >>> >>> Thanks >>> Scott >>> >>> On 13/04/2010, at 8:19 PM, Jacopo Cappellato wrote: >>> >>>> Sorry if I am hijacking this thread, but the more I think of it the more I >>>> believe we should officially create an "alpha" release 10.04, instead of >>>> simply creating a release candidate for 10.04. >>>> In this way we will have two official current releases: >>>> 09.04 Stable Release >>>> 10.04 Alpha Release >>>> >>>> Intended audiences: >>>> 09.04: final users with no interest (or resources) in helping the >>>> community to build and maintain stable releases >>>> 10.04: users (they could be service providers, end user companies with >>>> internal resources or longer term goals etc...) that are willing to help >>>> the community to build and maintain a stable release >>>> >>>> If there will be interest around the 10.04 alpha release, we will get bug >>>> fixes that will be part of a future 10.04.1 "stable" (bug fix) release (or >>>> a "beta" release), or even 10.04.2,3,4,5 etc... (each of them more stable >>>> than the predecessor). >>>> >>>> Jacopo >>>> >>>> On Apr 8, 2010, at 8:11 PM, Scott Gray wrote: >>>> >>>>> Just to be clear though, I am NOT in favor of back-porting large chunks >>>>> of functionality to the release branch under the guise of bug fixes. >>>>> >>>>> Regards >>>>> Scott >>>>> >>>>> On 8/04/2010, at 12:06 PM, Anil Patel wrote: >>>>> >>>>>> Looks like, none who participated in this thread have objections for >>>>>> merging of securitycontext20091231 branch with trunk. >>>>>> >>>>>> Thanks and Regards >>>>>> Anil Patel >>>>>> HotWax Media Inc >>>>>> Find us on the web at www.hotwaxmedia.com or Google Keyword "ofbiz" >>>>>> >>>>>> On Apr 7, 2010, at 7:46 PM, Scott Gray wrote: >>>>>> >>>>>>> Well I don't see any problem with dropping it in right now then. The >>>>>>> real question will be what do people want to be able to backport once >>>>>>> the release branch is created. >>>>>>> >>>>>>> Regards >>>>>>> Scott >>>>>>> >>>>>>> On 7/04/2010, at 5:35 PM, Adrian Crum wrote: >>>>>>> >>>>>>>> The security redesign implementation itself is mostly finished. There >>>>>>>> are a few TODOs and they can be found in the BranchReadMe.txt file. >>>>>>>> >>>>>>>> I recently synchronized the branch with the trunk and there is a >>>>>>>> remote chance something in the design might have broken in the >>>>>>>> process. I need to run some tests and review the code to see if that >>>>>>>> happened. >>>>>>>> >>>>>>>> The Example component has been switched over to the new design. >>>>>>>> >>>>>>>> There is a user login called "artifact-user" that demonstrates the new >>>>>>>> design. That user login is restricted to using the Example component. >>>>>>>> >>>>>>>> If the branch was merged back to the trunk and the new security design >>>>>>>> was enabled, the Example component would use the new design and the >>>>>>>> remaining components would still use the current security design. The >>>>>>>> two can co-exist. >>>>>>>> >>>>>>>> I imagine the process after that would be similar to when we >>>>>>>> introduced the permission checking services - contributors can >>>>>>>> contribute code that converts parts of the project over to the new >>>>>>>> security design. Conversion involves removing hard-coded permission >>>>>>>> checks and creating seed data to grant permission to component >>>>>>>> artifacts. >>>>>>>> >>>>>>>> As I mentioned before, switching a component over to the new design >>>>>>>> can create some unexpected problems. That's because our existing code >>>>>>>> has security holes in it, and the new design plugs those holes - >>>>>>>> making parts of the component unreachable. In other words, parts of >>>>>>>> code that happily allow you to do things you don't have permission to >>>>>>>> do will start to throw exceptions in the new design. >>>>>>>> >>>>>>>> -Adrian >>>>>>>> >>>>>>>> >>>>>>>> Scott Gray wrote: >>>>>>>>> Question: >>>>>>>>> What exactly is the current status of the execution branch? What is >>>>>>>>> it that needs to be done for it to be enabled in the trunk? >>>>>>>>> I'm sorry if you feel you've already answered that question but I'm >>>>>>>>> afraid it still isn't entirely clear to me. >>>>>>>>> Regards >>>>>>>>> Scott >>>>>>>>> On 7/04/2010, at 5:14 PM, Adrian Crum wrote: >>>>>>>>>> If we wait, then we're waiting for evaluation and testing of the >>>>>>>>>> branch. I've done all I can do - the code is written, I suggested we >>>>>>>>>> do the merge before the release branch, and I gave my reasons for >>>>>>>>>> suggesting it. >>>>>>>>>> >>>>>>>>>> At this point in time I have stepped out of the discussion (in a >>>>>>>>>> positive way) to give others a chance to look at the design and the >>>>>>>>>> code and decide for themselves if it should be included. In other >>>>>>>>>> words, I don't want to be in a position where I have to convince the >>>>>>>>>> community what it should do. If the design and the implementation >>>>>>>>>> are good, then there will be no need to convince anyone, right? >>>>>>>>>> >>>>>>>>>> I'll answer questions about the executioncontext branch, and I'll >>>>>>>>>> continue to work on it here and there when I have the time. If the >>>>>>>>>> release branch is created without it, then that will be fine with me. >>>>>>>>>> >>>>>>>>>> :-) >>>>>>>>>> >>>>>>>>>> -Adrian >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Scott Gray wrote: >>>>>>>>>>> Considering we have yet to do an official release after 3.5 years >>>>>>>>>>> and the lack of user interest in our release branches (partly >>>>>>>>>>> because we recommend the trunk to everybody), I think it would be a >>>>>>>>>>> waste of time and effort to create more than one release branch per >>>>>>>>>>> year. If we want the security branch in there then lets wait, >>>>>>>>>>> there is no good reason for us to release this month, it's just an >>>>>>>>>>> arbitrary date. >>>>>>>>>>> HotWax Media >>>>>>>>>>> http://www.hotwaxmedia.com >>>>>>>>>>> On 7/04/2010, at 12:07 AM, Jacopo Cappellato wrote: >>>>>>>>>>>> I would suggest to: >>>>>>>>>>>> 1) release 10.04 before the merge is done >>>>>>>>>>>> 2) merge the code to the trunk, switch to it, fix any possible >>>>>>>>>>>> issue >>>>>>>>>>>> 3) do another release (10.06?) >>>>>>>>>>>> >>>>>>>>>>>> I know this is not inline with what we currently think a release >>>>>>>>>>>> should be, but this is very inline with what the ASF practices and >>>>>>>>>>>> so I will continue to insist with the release-often practice. :-) >>>>>>>>>>>> >>>>>>>>>>>> Jacopo >>>>>>>>>>>> >>>>>>>>>>>> On Apr 4, 2010, at 8:21 PM, Adrian Crum wrote: >>>>>>>>>>>> >>>>>>>>>>>>> I would like to start bringing parts of the >>>>>>>>>>>>> executioncontext20091231 branch into the trunk before we create >>>>>>>>>>>>> the next release branch. The implementation of the new security >>>>>>>>>>>>> design is not finished, but it will be disabled - so everything >>>>>>>>>>>>> will still work the same. >>>>>>>>>>>>> >>>>>>>>>>>>> My goal is to allow users of the 10.x release to plan for the >>>>>>>>>>>>> forthcoming changes, and maybe have the conversion to the new >>>>>>>>>>>>> design completed by the release that follows 10.x. >>>>>>>>>>>>> >>>>>>>>>>>>> I will wait a few days, and if there are no objections I will >>>>>>>>>>>>> begin merging the design into the trunk. >>>>>>>>>>>>> >>>>>>>>>>>>> -Adrian >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> >
