cancel
Showing results for 
Search instead for 
Did you mean: 

How does development/bugfixing cycle works at Alfresco?

jonvargas
Confirmed Champ
Confirmed Champ
Hi,

I've been testing Alfresco for some time, and now I am very interested to know how does the development/bugfixing lifecycle works. So, several questions here, I would appreciate so much your help to continue using Alfresco:

1. Are Enterprise and Community sharing the same Subversion repository? Where is latest code being applied?

2. Are Community Editions (3.4.e for example) published on Alfresco's site just the latest available nightly build, or some extra work is performed for those releases?

3. Where are fixes applied when reported as 'fixed' on Jira, and how to get access to that fix or the build that includes it?

4. Does the build scripts provided in Alfresco's subversion repo will produce the same result as the nightly builds performed by Alfresco?

5. Which is the recommended tool for building/developing on Alfresco? (Netbeans, Eclipse)?

6. If I build alfresco.war/share.war using the code in SVN, is it just so simple as placing it in tomcat and restart it?

7. Does the available nightly builds are built against repo's HEAD at that moment?

8. How does Enterprise and Community versions numbers relate each one? What would be the versions match between an Enterprise and Community Edition?

9. What means each component in version number (_3_._4_._e_ for example) for Community and Enterprise?

Thanks in advance!
Your work is great.
4 REPLIES 4

mrogers
Star Contributor
Star Contributor
Your questions are well answered elsewhere, but here is a summary.

1. Are Enterprise and Community sharing the same Subversion repository? Where is latest code being applied?
Yes.  Code is being applied to HEAD and the Development and Enterprise branches.

2. Are Community Editions (3.4.e for example) published on Alfresco's site just the latest available nightly build, or some extra work is performed for those releases?
If you look ! there are nightly builds and other more stable releases.   You can also get releases from sourceforge.

3. Where are fixes applied when reported as 'fixed' on Jira, and how to get access to that fix or the build that includes it?
The Jira issue has a "fixed" property saying which version is fixed.    Then fixes are "merged forwards" or if you are an enterprise customer and the bug is serious they can occasionally be "reverse merged" into a service pack.

4. Does the build scripts provided in Alfresco's subversion repo will produce the same result as the nightly builds performed by Alfresco?
Yes.  Except for some of the packaging tools which we can't distribute due to their licence restrictions.    You can produce an identical build.

5. Which is the recommended tool for building/developing on Alfresco? (Netbeans, Eclipse)?
There is no reccomended tool.   However most Alfresco developers tend to use Eclipse.

6. If I build alfresco.war/share.war using the code in SVN, is it just so simple as placing it in tomcat and restart it?
Yes.   Except for a little setup which is documented on the wiki.  You will also need to set up the shared folder in tomcat, the database and the other third party dependecies.

7. Does the available nightly builds are built against repo's HEAD at that moment?
Sort of.  Its HEAD as of some point in the past.   May be last night, or this morning or could be longer if there's a problem.

8. How does Enterprise and Community versions relate each one? What would be the versions match between an Enterprise and Community Edition?
The versions start at the same place and cross from time to time.    Generally Enterprise lags behind community and then overtakes.

jonvargas
Confirmed Champ
Confirmed Champ
Thank you so much mrogers for the quick summary, it really clarifies my dudes and pushes me to perform a build of alfresco safely.

I still have a dude in Community and Enterprise version matching.

For example I reported a bug for Community but QA said it was fixed for Enterprise 3.4.1, then I recently tried 3.4.e and the bug still exists. So, either 3.4.e is a not so up-to-date version (almost 4 months ago) or the fix is not still applied in SVN. And, how should I interpret 3.4.1 version number if I am a Community user? I mean, how do I notice if it comes into a Community Edition or a nightly build for example?

I just looked at the revision number of 3.4.e, checked out HEAD's code, and there are around 1800 revisions between. I was unable to see when 3.4.e revision was commited because 'svn log -v -r 26807' returns nothing, so I don't know how old it is, but I think that 1800 revisions tells me it is old. Am I right?

Thanks again in advance.

Your questions are well answered elsewhere, but here is a summary.

1. Are Enterprise and Community sharing the same Subversion repository? Where is latest code being applied?
Yes.  Code is being applied to HEAD and the Development and Enterprise branches.

2. Are Community Editions (3.4.e for example) published on Alfresco's site just the latest available nightly build, or some extra work is performed for those releases?
If you look ! there are nightly builds and other more stable releases.   You can also get releases from sourceforge.

3. Where are fixes applied when reported as 'fixed' on Jira, and how to get access to that fix or the build that includes it?
The Jira issue has a "fixed" property saying which version is fixed.    Then fixes are "merged forwards" or if you are an enterprise customer and the bug is serious they can occasionally be "reverse merged" into a service pack.

4. Does the build scripts provided in Alfresco's subversion repo will produce the same result as the nightly builds performed by Alfresco?
Yes.  Except for some of the packaging tools which we can't distribute due to their licence restrictions.    You can produce an identical build.

5. Which is the recommended tool for building/developing on Alfresco? (Netbeans, Eclipse)?
There is no reccomended tool.   However most Alfresco developers tend to use Eclipse.

6. If I build alfresco.war/share.war using the code in SVN, is it just so simple as placing it in tomcat and restart it?
Yes.   Except for a little setup which is documented on the wiki.  You will also need to set up the shared folder in tomcat, the database and the other third party dependecies.

7. Does the available nightly builds are built against repo's HEAD at that moment?
Sort of.  Its HEAD as of some point in the past.   May be last night, or this morning or could be longer if there's a problem.

8. How does Enterprise and Community versions relate each one? What would be the versions match between an Enterprise and Community Edition?
The versions start at the same place and cross from time to time.    Generally Enterprise lags behind community and then overtakes.

mrogers
Star Contributor
Star Contributor
3.4.e was a bit unusual since it's a community "preview release" for Activiti.    One of the engineering features of that release is that HEAD was kept stable for a long time while activiti was integrated and tested, and in particular all other changes including bug fixes were blocked.   So theres easily a backlog of four months for minor bug fixes on that particular version since it was not intended to be a "bug fix" release.

All Enterprise 3.4.1 (and probably 3.4.2) bug fixes should be on head now.    The usual pattern is for changes to be merged fairly quickly once a release is validated since the longer the merge is delayed the worse it becomes.

jonvargas
Confirmed Champ
Confirmed Champ
Thank you so much again. Good and response mrogers. 🙂

3.4.e was a bit unusual since it's a community "preview release" for Activiti.    One of the engineering features of that release is that HEAD was kept stable for a long time while activiti was integrated and tested, and in particular all other changes including bug fixes were blocked.   So theres easily a backlog of four months for minor bug fixes on that particular version since it was not intended to be a "bug fix" release.

All Enterprise 3.4.1 (and probably 3.4.2) bug fixes should be on head now.    The usual pattern is for changes to be merged fairly quickly once a release is validated since the longer the merge is delayed the worse it becomes.