Version control of published AxShare links

#1

Hi,

We are currently looking into using Team Projects to help better manage design changes that are picked up by developers. I was wondering if it’s possible to somehow version control the published HTML on AxShare so we are not always overwriting the same link.

e.g. share.axure.com/123456 would always point to latest version, but share.axure.com/123456/2 would point to version 2 etc.

The only other way of doing this is to publish each version to a different link in a folder, but as we publish those links elsewhere, it would create maintenance difficulties for us.

#2

Hi webade,

I’m afraid there isn’t currently a solution other than using a different link for each check-in. We’re going to be adding features for team projects on AxShare during the beta. This particular issue is definitely on our list to address.

Rachel

#3

Thanks for the reply. Would be a real improvement to our current workflow if this was possible.

#4

Will just add that we have the exact same issue with Axure.

In the perfect world, we would like:

  • Automatic versioning on AxShare. Publish to AxShare and let AxShare save the old versions of the wireframes/flows
  • Easy overview of which wireframes/flows that were changed between two versions/releases
  • A way to get a graphical overview of differences between two versions of the same wireframe/flow.
#5

I believe you can achieve this by sharing your prototype. In Axure 8 under Team (Pro) menu Create Team Project from Current File… this will create a version control RP file. So now when you check-in/out pages you will have the ability to go back to that version.

I do this quite often so I have version control even when I’m not sharing the file with anyone.

#6

Any news on this topic? we would need this functionality for several projects.

#7

Hi mpohlmann_MRM,

No news as of yet, and I’ll be updating our product team about your recent post. Do feel free to elaborate on your workflow, too, which may help shape the kind of solution we evaluate and its implementation. Thank you!

#8

Any updates since August? My team could utilize this feature as well. Primary use is for Product Owners or Developers to view the historical changes of a design to the most recent.

#9

Hi Alex,

Here’s our workflow:

We have a few people with an Axure Licence (UX and some BAs) who create Axure files but then publish out to Axure Share for stakeholders including developers and QA. It is for those users where version control becomes important as we need to keep a tight control of changes that are made to wireframes/prototypes during development sprints. These users don’t have Axure so team project wouldn’t solve their problems.

Any more information let me know,

Adrian

#10

In my workflow I need versioning for sprints. We have 2 week sprints and I need to show the devs what features are going in that sprint. So being able to create a version that’s specific to a sprint would greatly aid my efforts in reducing hard versions.

#11

This topic (yet again) came up when I was called into a meeting with the Director of Development asking for version control. The only method I have is to take screen shots to attach to the the sprint stories, but that loses all functionality (obviously).

#12

My team and I are running into similar challenges.

Some ideas/solution to mitigate, but not solve the situation:

  1. In an external lifecycle management tool (e.g. Jura, Rally, etc.), each User Story (US) would have a link to the relevant page in the AxShare repository.

  2. Take feedback and approvals from clients on the AxShare platform. Once clients put an “APPROVED” comment on a page, we regard it as approved. To mark it, we add the string [APPROVED] to the beginning of the name of the page. Once a page is approved, we do not make any further changes to it.

  3. Each iteration or spring would have it’s own folder, with just the pages that were updated. The great con of course is not being able to find older pages. It also makes it hard to understand what the latest and greatest version of each page looks like.

  4. We are considering creating a fresh copy of the entire system for each release. That would solve the concerns above, but would create new difficulties, such as enormous project files, and also hard to see what was updates in this release or iteration.

Any thoughts or ideas how to overcome this?

#13

Will there be anything to solve this issue in Axure 9? This thread is over 3 years old and there doesn’t seem to be a solution, only work-arounds.

#14

I realize this might not be an entirely helpful or entirely accurate comment to add to this thread, but I believe at a previous job, we used beanstalk (beanstalkapp.com) as an SVN repository to store our team project. There may have been some hiccups to it, but I think we had version control. Apologies if this isn’t a comment that truly advances this conversation (I know it too is just a workaround compared to having version control on Axure Teams/Axshare.)
Jacque

#15

Hello, Rachel, is there any news re this? I could not find any.

On my project we have similar troubles as mentioned before.

  1. It would greatly helped us if there was a possibility to view older versions of the page. Preferably not versions of screen aka atomic commits, but software versions like 1.0.1. and 1.0.2.
  2. If we could compare versions between themself, that would be a blast.

Any of here (and elsewhere) mentioned hacks do not do the trick, at least what I saw until now.

#16

I guess keeping the discussion on this going might push this higher on the Axure backlog, but we are also really waiting for this.

If only Viewers could click a revision in the History list to see the generated prototype for that revision. Heck, could even generate on the fly.

#17

Have there been any solutions to this problem with Axure 9. I have not been able to find one for read only users. It seems the best course of action is to just make a new file and a new axure share link for a new version.
Will