Picture of Dick Moore
Getting the beta up and kicking
by Dick Moore - Friday, 25 April 2014, 1:35 PM
 

Hello Sven and fellow adepts (sorry)

I am working in Ubuntu and have build a prototype course that is looking good.

I got the cli framework up and kicking using the master frame work but would like to have a go at using V1.1 alpha.  Clearly much more than just typing in develop when building the course,

Should I do a fresh git clone of the development track than deploy the beta2 zip file in the home directory.  I am really liking what It can do but really need some of the V1,1 functionality for my project due to be delivered in June so keen to get a head start and a look around.

Thanks in advance 

Dick 

 

Picture of Chris Jones
Re: Getting the beta up and kicking
by Chris Jones - Friday, 25 April 2014, 3:11 PM
 

Hi Dick,

v1.1 is still "work in progress" so I would strongly recommend working with v1.0 as it is the current stable release. The development branch does not represent production release code and performance, appearance and API may differ when the v1.1 release happens.

Additionally each plugin in the contrib core has to be upgraded due to some breaking changes so right now is not the best time to be previewing the code as some plugins will work and some will still be incompatible.

The development branch is publicly available on GitHub, but we don't feel that the currently unstable nature of the incomplete code truly represents how we want v1.1 to be perceived. 

Hope you can understand that there may be some people who try out the development code and get put off by it even if it does not represent the finished product.

Chris

 

me
Re: Getting the beta up and kicking
by Sven Laux - Friday, 25 April 2014, 3:29 PM
 

Hi Dick,

thanks for your note and good to hear you're working on an Adapt project and liking the v1.1 functionality!

The next release of the Adapt Framework (i.e. v1.1) is due before the end of May this year, i.e. within around a month's time. The steering group have just agreed that high code quality and stability are essential for the project and we have just reflected this in an update to our principles page.

We are committed to keeping up the high quality bar we have set and this takes time. Having said that, we're not far off. While we can't make any guarantees about the timelines, the resources and testing cycles are booked in and we are quietly confident we can meet these. 

With this in mind, yes, the BETA code is available and nobody would stop you from manually building your project on this. However, the official line from the core team has to be that we would advise against this for several reasons (all vaguely related to quality):

  • no support for the BETA code
  • no upgrade path / not in version control
  • already out of date (given various fixes and additions)
  • etc.

Other views are welcome, of course! Maybe someone in the community has had some experience actually trying 1.1 to build a live project?

Thanks,
Sven

PS: We will shortly add a roadmap page and more detail on the next release and our thoughts on release management. I'm keen to get people's views on this once the thread is up.

 

Picture of Dick Moore
Re: Getting the beta up and kicking
by Dick Moore - Friday, 25 April 2014, 4:10 PM
 

Hi Sven Chris 

Thanks for responding :)  I have got a course shell built and up and running, is there going to be a migration script to V1,1 or will it be a rebuild?  Having been in your shoes I know what I am asking here and if you say nope V1,1 is so different you will need to do a rebuild I understand why and where you are coming from.

I did a git clone last night on the development track and ran into a little trouble with missing CSS stuff but I could see were you are going   I will continue to play,

I have a couple of newbie questions that I will create in a new post.

Thanks and have a good weekend.

Dick 

 

 

 

 

 

me
Re: Getting the beta up and kicking
by Sven Laux - Friday, 25 April 2014, 4:46 PM
 

Hi Dick,

thanks. At this point we know that there are 'breaking changes' (as Daryl calls them) when going to framework version v1.1. The worst case scenario is therefore an incompatibility and for users to be forced to rebuild to get the new features.

This is not ideal and has prompted a strategic discussion about release management, which will will document and put up for discussion with the community. The idea of this is that we will get into a position where we avoid breaking changes going forward or at least find way of tackling them via migration scripts. I'll have to add that this is my personal opinion and that this point will need more discussion with the team.

I can see that as more data becomes editable through the authoring tool we may find ourselves reconsidering the JSON data structures so I feel we need an official line and commitment on release management and compatibility between versions.

Hope this makes sense - please watch this space / add opinion.

Sven

 

Picture of Dick Moore
Re: Getting the beta up and kicking
by Dick Moore - Wednesday, 30 April 2014, 8:14 PM
 

Sven

Release management

This is a philosophical and adoption point here its not always possible to be backwards compatible when you are introducing new features and I would understand if V11 was not backwards compatible with V1.0 which is after all a beta.

The key questions are about long term mainteance  costs and TCO if Adapt is to produce courses that are build deployed and used then this is not a problem, but it seems much more capable than that I would encourage you to build in backwards compatability  if possible, even if its done with migration scripts.  

Clearly  if people move from the straight and narrow and introduce their own code then that's their issue.  Long term viability of an open source project is all about the non-functional requirements.  The bash scripts I wrote 20 years ago still work :)

Adding to JSON

I really like the elegance of holding all the content in json and can see how this will give the project a very long life.  I am already thinking about storing each doc as a seperate document in git or on a mongo server and the doing a pull, assemble, build and release.

If you can keep it to json + ,media assets then that gets my vote for what its worth.

I pushed my first adapt course into a Moodle server today - some issues (see latest post) but it went in like a dream.

Best wishes

D