Home › Forums › Developers › General developer's discussion ›

Development Workflow

Submitted by Ben_Charlton on Fri, 24/04/2015 - 15:59
in

I must admit watching the User forums at the moment ...it seems like you launch a beta and suddenly the feature requests come in thick and fast..

Seems to me for future iterations we might need a clearer development timeframe and milestones. 

Something along the lines of 

1. Open for feature requests

2. Publish alpha with funded requests

3. Publish alpha2 and close feature requests. ie Feature freeze

4. publish beta - bugfixes and minor changes only no new features

5. publish release

We might never make it out of 1.8 beta with all the new options requested.  not that I am complaining its great to see a user group actively push a project.  But adding features that change core archetypes after we enter beta should be sort of a nono as TimA pointed out certain sites are using 1.8 beta in production, archetype changes at this stage should be locked.

Additionally I would think that we could start to run a alpha test system again in addition to the demo system to show cast the latest beta or alpha.

‹ Upgrade 1.7->1.8 Test Warnings from update.sql specific to users that use REPLICATION Struggling with Xpath development ›

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Re: Development Workflow

Submitted by tanderson on Tue, 28/04/2015 - 10:18.

Agreed. I think we also should publish the release that a project was released/will be released under in the project listing at http://www.openvpms.org/projects

Currently the only way to do find this out is by navigating to the JIRA.

I'll update the alpha site when I publish the next beta-2 snapshot.

 

Re: Development Workflow

Submitted by tgething (not verified) on Tue, 28/04/2015 - 13:12.

Tim - do you want me to add a 'target release' field to the Development Project content.  I think that the thing to do is to make it a mandatory radio button field with the choices 1.8, 1.9, 1.10, 1.11, and Future

Regards, Tim G

Re: Development Workflow

Submitted by tanderson on Tue, 28/04/2015 - 13:59.

That would be great thanks. Maybe call it Release instead of Target Release however.

In order to tag projects in past releases, can you also include 1.4, 1.5, 1.6 and 1.7 as well?

Re: Development Workflow

Submitted by tgething (not verified) on Tue, 28/04/2015 - 15:23.

DONE - this is what it looks like for a project with a Release set

In Projects that do not have a Release set, the highlighted data is just omitted.

Note that I made the field non-mandatory - and its default is  N/A - ie not set.

At any time, someone with appropriate privileges can set or change the Release.

I will delete this test project in a couple of days.

Regards, Tim G

Re: Development Workflow

Submitted by tanderson on Tue, 28/04/2015 - 16:03.

Can the release be displayed in the http://www.openvpms.org/projects page? The Created column could be dropped to make room.

Thanks,

-Tim A

Re: Development Workflow

Submitted by tanderson on Wed, 29/04/2015 - 15:43.

I've gone through and updated half of the completed projects. The sorting is an issue. Can they be sorted on Status, Release, and Project?

Thanks,

-Tim A

Re: Development Workflow

Submitted by tgething (not verified) on Wed, 29/04/2015 - 17:03.

Sorry - I went to bed last night still trying to figure out how to add Release to the sortable columns.  Will re-visit now.  Regards, Tim G

Syndicate content