Gemini Community Support Site

This Gemini community support site can be used to find solutions to product issues. You can log in using Open Id, Google Profile and even Facebook. Feel free to ask a question or browse FAQs and documentation. Product tour videos are also available along with how-to videos demonstrating key Gemini capabilities.




Process this :)

web-app

Hi guys

What do you think is the best way to process this with gemini?

Let's say I have a software project which has betas, release candidates etc etc. Or the usual things.

I want to track changes between version so I resolve all issues to beta version/rc's in the roadmap. I want everyone to see this is the roadmap with all these RC issues etc. So that's no problem.

Then when it comes to the full final release, I want to show the end user all the issues in the changelog. I want to show all issues under the final release version, NOT all the beta or RC versions etc! That means all the beta issues, rc version etc would have to be compiled together under one version.

Is this possible right now? Maybe there is a public version number and a private version number?
Does upgrading to version 3 help here?

In summary I am asking for a public view for the roadmap, and a private view. Public view shows all the beta's etc compiled together as one "full release" (so they don't actually see the beta version, just the all issues compiled for that release), and private would show the real story between all the releases.

Does this make sense?

Cheers!

Alex

Nuke AlexS
· 1
Nuke AlexS
Replies (5)
helpful
0
not helpful

Hmmm...

Will you have different versions for RC/beta releases?  I guess so by what you are saying.  If so, then you cannot do this in Gemini.

However....

1. Create a single version, e.g.1.0.0 release.
2. Create a global custom field like "Internal Version" that is a dropdown list of things like Beta 1, RC1, RC2.
3. Change Field Visibility Schemes so that only "internal" users see this new Custom Field of Internal Version.
4. You can then optionally, completely hide issues from the "public" users by using Issue Visibility.

This would result in a single public facing version with all issues logged against it, but with a custom field to help you determine which internal version each issue relates to (e.g. beta 1), and still allow you to completely hide issues from public view usin Issue Visibility.

?!




Harvey Kandola
· 212
Harvey Kandola
helpful
0
not helpful

Sounds interesting Harvey thanks..

In a nutshell the official release version will have all the issues the RC and Beta had assigned to it.
We are assuming that the end user does not care about RC's or Beta's just the full version. I guess you call this a "version grouping or something".

However we care about RC's and Beta's internally so we can track them!

Maybe this is a good idea for an enhancement, you can see the use case?

Not such a bad day here in the UK is it!

Cheers

Alex


Nuke AlexS
· 1
Nuke AlexS
helpful
0
not helpful

Feel free to add it to our list: http://gemini.countersoft.com

 


Saar Cohen
· 5000
Saar Cohen
helpful
0
not helpful

Done! (GEM-1880)

Thanks...


Nuke AlexS
· 1
Nuke AlexS
helpful
0
not helpful

I added another request (GEM-1979) that I think is very similar so I've grouped it with it.  I need a field for build number.  I want my developers to be able to indicate in which build a fix will show up so my testers will know to verify the fix in that build.  I don't want them re-opening issues because they don't think something was fixed when in fact it was fixed after a build was generated.

I also can't allow my developers to edit issues so I would like them to be able to change the build number when they are adding a comment which is when they also change the status and resolution fields.  I can't do this with a custom field.


ESteinweg
· 1
ESteinweg